walle303When RAID56 is ready for production use, it'll be possible to switch to it with a rebalance right?
WaxheadA while ago I asked about if there was any interest in boosting btrfs' read speed by not using the PID% for finding stripes. Earlier attempts such as cnt++ + PID% did not improve performance as much either I was told. I am curious. Have anyone tried cnt++ / somevalue + PID% instead ? That way you would read from a disk for some time before moving on to the other one.
Kobazi suppose you could benchmark one vs the other
Waxheadperhaps ... unless someone have tried already or have something cooler up the sleeve
PiesKobaz: fragmented free space doesn't seems to be a problem - I compared year old slower system, and fresh system with rsynced data and faster writes and graph looks very similar
Pieshttps://cloud.opcja.pl/index.php/s/bHUUPARsvthxBoH - heatmaps
kaulian_Hi all
kaulian_I'm back with my readonly brtfs partition ...
multicorekaulian: did you check your hw?
kaulianmulticore: yes
multicorekaulian: how?
kaulianfound windows ...
kaulianinstall the tools of WD
kaulianit says RAID 0 is OK
multicorekaulian: the issue isn't with your hdd
kaulianmulticore: i tried yeserday
multicorekaulian: how did you check your ram/mb/psu/cpu ?
kaulian_multicore: it was a third device
kaulian_multicore: i can mount partition and explore it
kaulian_multicore: the partition changed in ro after a minute
multicorekaulian_: yes, because you have metadata corruption
multicorekaulian_: which happened before it was written to the hdd
multicorekaulian_: if latest btrfs-progs --repair can't fix the corruption you'll need ask help from mailing list or try to fix the problem by yourself
multicorekaulian_: but don't try to fix the issue if you have unstable hw
kaulian_multicore: but hardware seems ok
kaulian_multicore: western digital tools says everything ok
multicorekaulian_: are you trolling?
kaulian_multicore: no... i don t have other solution to test the second disk =)
multicorekaulian_: i've said multiple time that the issue isn't with your hdd
kaulian_multicore: ok... but 3 computers and same problem
kaulian_multicore: last things not changed is usb cable
multicorekaulian_: computer A corrupts data before it's written to hdd
multicorekaulian_: no you have corrupted data
kaulian_Knorrie: yes usb.. i love danger
multicorekaulian_: you can try it with n+1 computers with same results
kaulian_multicore: ok but do you thing there ia solution to fix it ?
multicorekaulian_: did you try btrfs check with latest btrfs-progs?
kaulian_I try with the last release of archlinux
kaulian_so 4.13
waldo_I'm in the middle of a 'remove device' operation on a raid 5 array, which, if i calculated right is going to take another 3 weeks (its been going for a week) to complete. Its running on an atom 8 core and i can constantly see a btrfs process hugg one complete core either btrfs or btrfs-transactio. In dmesg I can see i keeps moving block so things seem to move along but f*cking slow.
waldo_Anything I can do to move this along ? And more important, what if I need to reboot the machine and/or there is a new kernel (currently at 4.12.4-1)
Kethese are the raid5 problems
waldo_ok, i can accept that, i have backups (mostly :D) anything about the reboot question
KeI don't think reboot is going to be a problem
waldo_So i'm corrent in assuming theres no cancel option for delete device, and it will resume after a reboot ?
Kehmm, not sure
KeI don't think it resumes
waldo_in btrfs fi sh its size is already 0 (used 1.86TiB) so how would that work then ....
waldo_delete it again ?
hadrian2003Hi is there a possibility, to skip checksum check when doing btrfs rescue chunk recover
hadrian2003somehow after a reset my chunk tree is broken, especially the root
multicorewaldo_: more snapshots and/or quota slows down the process...
Hugo_I'm attempting to recover a btrfs volume - btrfs restore allowed most files to be obtained, but I'd like to still recover the filesystem if possible. Attempting to ' mount -t btrfs -o recovery /dev/mapper/system-root /tmp/root' results in 'can't read superblock on /dev/mapper/system-root' and any repiar attempts 'btrfs check --repair --check-data-csum /dev/mapper/system-root' or with --init-csum-tree or other options all core dump
Hugo_checksum verify failed on 771301376 found C8D5C662 wanted 45D60E5E Csum didn't match extent-tree.c:2727: alloc_reserved_tree_block: BUG_ON `ret` triggered, value -17 btrfs[0x423e46] btrfs[0x424efc] btrfs[0x424fb6] btrfs(btrfs_alloc_free_block+0xc4)[0x429474] btrfs(__btrfs_cow_block+0x182)[0x419af2] btrfs(btrfs_cow_block+0x10a)[0x41a2fa] btrfs[0x41f9f7] btrfs(btrfs_commit_transaction+0x98)[0x421728] btrfs(cmd_check+0xa26)[0x45df36] btrfs(m
Hugo_Any chance this still might be recoverable?
WaxheadI popped in here yesterday nagging a bit about the volumes.c file and especially current->pid % map->num_stripes. I am just a hobby C coder and no kernel wacker-hacker so I had trouble compiling and testing the kernel on Debian. However I think that a minor adjustment (with potentially a tuneable) could do wonders distributing reads compared to todays version. http://codepad.org/xIg4geoN - is this simple twist something that has been trie
Waxheadd by the pros?
snkcldif i set "compression zstd" on "/", then i have nested subvols created, do they inherit those properties/
snkcldi guess what im asking is do subvolumes inherit properties
Kelsari think compress=zstd is global
urmetsnkcld: compress mount flag is global
snkcldurmet: i am talking about the property though
snkcldlike, if i set a property on a directroy
multicoresnkcld: should be easy enough to test?
multicoresnkcld: also you don't want to set zstd compression to your /boot
snkcldmulticore: in fact its not easy to test because there isnt exactly an easy way to determine the 'actual' disk usage versus 'compressed' usage
snkcldtheres a 3rd party tool that kind of helps on that but its not as though i can say "btrfs get-me-the-real-size-vs-compressed-size /blah"
snkcldmulticore: /boot is mounted via a seperate fs entirely (ext4)
multicoresnkcld: filefrag -v tells you if there's encoded extents
snkcldencoded extents?
snkclddoes that indicate compression?
multicoresnkcld: what's the 3rd party tool you're referring to?
snkcldmulticore: https://github.com/kilobyte/compsize
snkcldpretty much gives me exactly what im looking for. would be nice if that functionality existed in btrfs-progs :)
snkcldmulticore: with "btrfs fi show /"
snkcldi see "devid 1 size 100.00GiB used 72.03GiB path /dev/mapper/vg1-ubuntu"
snkcldis that 72.03 like... the amount of space that is used.... compressed value and all?
snkcldthat is, is the 72.03 an indication of the sum of the file sizes uncompressed?
snkcldor is it like, the amount of space used to store the files, compressed or not?
multicoresnkcld: it isn't neither
snkcldlol didnt realize there was a 3rd option
multicoresnkcld: you have 72 of 100 allocated
rossomescrub finished after 184:47:20 total bytes scrubbed: 28.51TiB with 0 errors
rossomedamn that took some time
rossomeraid5 still going strong after 3+ years
urmet3+ year scrub? :D
gehidoremore like 1 week if that's hours minutes seconds