On 2018年06月29日 14:59, Marc MERLIN wrote: > On Fri, Jun 29, 2018 at 02:29:10PM +0800, Qu Wenruo wrote: >>> If --repair doesn't work, check is useless to me sadly. >> >> Not exactly. >> Although it's time consuming, I have manually patched several users fs, >> which normally ends pretty well. > > Ok I understand now. > >>> Agreed, I doubt I have over or much over 100 snapshots though (but I >>> can't check right now). >>> Sadly I'm not allowed to mount even read only while check is running: >>> gargamel:~# mount -o ro /dev/mapper/dshelf2 /mnt/mnt2 >>> mount: /dev/mapper/dshelf2 already mounted or /mnt/mnt2 busy > > Ok, so I just checked now, 270 snapshots, but not because I'm crazy, > because I use btrfs send a lot :) > >> This looks like super block corruption? >> >> What about "btrfs inspect dump-super -fFa /dev/mapper/dshelf2"? > > Sure, there you go: https://pastebin.com/uF1pHTsg > >> And what about "skip_balance" mount option? > > I have this in my fstab :) > >> Another problem is, with so many snapshots, balance is also hugely >> slowed, thus I'm not 100% sure if it's really a hang. > > I sent another thread about this last week, balance got hung after 2 > days of doing nothing and just moving a single chunk. > > Ok, I was able to remount the filesystem read only. I was wrong, I have > 270 snapshots: > gargamel:/mnt/mnt# btrfs subvolume list . | grep -c 'path backup/' > 74 > gargamel:/mnt/mnt# btrfs subvolume list . | grep -c 'path backup-btrfssend/' > 196 > > It's a backup server, I use btrfs send for many machines and for each btrs > send, I keep history, maybe 10 or so backups. So it adds up in the end. > > Is btrfs unable to deal with this well enough?
It depends. For certain and rare case, if the only operations to the filesystem are non-btrfs specific operations (POSIX file operations), then you're fine. (Maybe you can go thousands snapshots before any obvious performance degrade) If certain btrfs specific operations are involved, it's definitely not OK: 1) Balance 2) Quota 3) Btrfs check > >> If for that usage, btrfs-restore would fit your use case more, >> Unfortunately it needs extra disk space and isn't good at restoring >> subvolume/snapshots. >> (Although it's much faster than repairing the possible corrupted extent >> tree) > > It's a backup server, it only contains data from other machines. > If the filesystem cannot be recovered to a working state, I will need > over a week to restart the many btrfs send commands from many servers. > This is why anything other than --repair is useless ot me, I don't need > the data back, it's still on the original machines, I need the > filesystem to work again so that I don't waste a week recreating the > many btrfs send/receive relationships. Now totally understand why you need to repair the fs. > >>> Is that possible at all? >> >> At least for file recovery (fs tree repair), we have such behavior. >> >> However, the problem you hit (and a lot of users hit) is all about >> extent tree repair, which doesn't even goes to file recovery. >> >> All the hassle are in extent tree, and for extent tree, it's just good >> or bad. Any corruption in extent tree may lead to later bugs. >> The only way to avoid extent tree problems is to mount the fs RO. >> >> So, I'm afraid it is at least impossible for recent years. > > Understood, thanks for answering. > > Does the pastebin help and is 270 snapshots ok enough? The super dump doesn't show anything wrong. So the problem may be in the super large extent tree. In this case, plain check result with Su's patch would help more, other than the not so interesting super dump. Thanks, Qu > > Thanks, > Marc >
signature.asc
Description: OpenPGP digital signature
