On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote: > Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White: > > On 12/26/2014 05:37 AM, Martin Steigerwald wrote: > > > Hello! > > > > > > First: Have a merry christmas and enjoy a quiet time in these days. > > > > > > Second: At a time you feel like it, here is a little rant, but also a bug > > > report: > > > > > > I have this on 3.18 kernel on Debian Sid with BTRFS Dual SSD RAID with > > > space_cache, skinny meta data extents – are these a problem? – and > > > > > compress=lzo: > > (there is no known problem with skinny metadata, it's actually more > > efficient than the older format. There has been some anecdotes about > > mixing the skinny and fat metadata but nothing has ever been > > demonstrated problematic.) > > > > > merkaba:~> btrfs fi sh /home > > > Label: 'home' uuid: b96c4f72-0523-45ac-a401-f7be73dd624a > > > > > > Total devices 2 FS bytes used 144.41GiB > > > devid 1 size 160.00GiB used 160.00GiB path > > > /dev/mapper/msata-home > > > devid 2 size 160.00GiB used 160.00GiB path > > > /dev/mapper/sata-home > > > > > > Btrfs v3.17 > > > merkaba:~> btrfs fi df /home > > > Data, RAID1: total=154.97GiB, used=141.12GiB > > > System, RAID1: total=32.00MiB, used=48.00KiB > > > Metadata, RAID1: total=5.00GiB, used=3.29GiB > > > GlobalReserve, single: total=512.00MiB, used=0.00B > > > > This filesystem, at the allocation level, is "very full" (see below). > > > > > And I had hangs with BTRFS again. This time as I wanted to install tax > > > return software in Virtualbox´d Windows XP VM (which I use once a year > > > cause I know no tax return software for Linux which would be suitable for > > > Germany and I frankly don´t care about the end of security cause all > > > surfing and other network access I will do from the Linux box and I only > > > run the VM behind a firewall). > > > > > And thus I try the balance dance again: > > ITEM: Balance... it doesn't do what you think it does... 8-) > > > > "Balancing" is something you should almost never need to do. It is only > > for cases of changing geometry (adding disks, switching RAID levels, > > etc.) of for cases when you've radically changed allocation behaviors > > (like you decided to remove all your VM's or you've decided to remove a > > mail spool directory full of thousands of tiny files). > > > > People run balance all the time because they think they should. They are > > _usually_ incorrect in that belief. > > I only see the lockups of BTRFS is the trees *occupy* all space on the device. No, "the trees" occupy 3.29 GiB of your 5 GiB of mirrored metadata space. What's more, balance does *not* balance the metadata trees. The remaining space -- 154.97 GiB -- is unstructured storage for file data, and you have some 13 GiB of that available for use. Now, since you're seeing lockups when the space on your disks is all allocated I'd say that's a bug. However, you're the *only* person who's reported this as a regular occurrence. Does this happen with all filesystems you have, or just this one? > I *never* so far saw it lockup if there is still space BTRFS can allocate from > to *extend* a tree. It's not a tree. It's simply space allocation. It's not even space *usage* you're talking about here -- it's just allocation (i.e. the FS saying "I'm going to use this piece of disk for this purpose"). > This may be a bug, but this is what I see. > > And no amount of "you should not balance a BTRFS" will make that perception go > away. > > See, I see the sun coming out on a morning and you tell me "no, it doesn´t". > Simply that is not going to match my perception. Duncan's assertion is correct in its detail. Looking at your space usage, I would not suggest that running a balance is something you need to do. Now, since you have these lockups that seem quite repeatable, there's probably a lurking bug in there, but hacking around with balance every time you hit it isn't going to get the problem solved properly. I think I would suggest the following: - make sure you have some way of logging your dmesg permanently (use a different filesystem for /var/log, or a serial console, or a netconsole) - when the lockup happens, hit Alt-SysRq-t a few times - send the dmesg output here, or post to bugzilla.kernel.org That's probably going to give enough information to the developers to work out where the lockup is happening, and is clearly the way forward here. Hugo. -- Hugo Mills | w.w.w. -- England's batting scorecard hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: 65E74AC0 |
Attachment:
signature.asc
Description: Digital signature
