Hello Graham and all, On 2013-07-04 T 18:03 +0100 Graham Anderson wrote:
On Thursday 04 Jul 2013 11:54:05 Jeff Mahoney wrote:
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
On a several desktops and two small hosts and several VMs with limited size (20GB) root volumes, I had to disable/remove snapper and manually delete all the snapper created sub volumes. Without warning, the root volumes became un- writeable with write operations from various services and applications reporting no available space.
I understand why df/du and monitoring tools are unable to correctly report free space in the same way that we are used to with more traditional non COW filesystems; but unless we educate users/admins about "btrfs filesystem df" or improve the various traditional reporting tools I bet the problem is going to bite more people.
I didn't investigate the problem further to determine whether it was a lack of space for meta information/extents or whether the sheer number of subvolumes (even with COW) was taking up the space.
The problem generally manifested itself after a medium period of about 3-4 months use, but on one desktop and one VM which were heavily used for testing packages, the problem appeared within a few weeks. Not good at all...
Admittedly, this is the concern I hear most often, and it is (at least to a certain degree) based on too "snapshot friendly" settings in the Snapper configuration for "/" (root). Or to put it differently: Snapper should delete older snapshots much more frequently and aggressivly. I would propose a Snapper update to enforce this also on 12.2 and 12.3. Something like this (pseudo code): if ( Snapper-config-for-"root" has default values ) { Change to more aggressive values } else { Do not touch the configuration, but issue a warning that the administrator should change this manually } What do you think? [...]
The second issue I ran into was a while ago and I apologise for no bug report on this one (I had no clue if btrfs was even officially supported in yast at the time). I can't remember the specifics but I was manually creating a btrfs filesystem with either multiple physical disks or md devices. The system partitioner (yast) was unable to recognise the filesystem; but what's worse is that I was able to add a btrfs filesystem via yast to the same physical or md devices that I had already manually created an fs on.
That sounds weird. If you run into it again, please create a bugreport.
In general, btrfs support in yast appears fairly limited and I would imagine I'd get really pissed off in future if the only supported brtfs use was via yast and that didn't allow for what I imagine will be fairly popular btrfs usage (multiple physical devices for large storage system). So I guess what I'm saying is I'd love to see some more love for btrfs in YAST with better support for btrfs options ;)
Everything needs a start -- so did btrfs support in the YaST partitioner. I see a request for RAID 1 support in openFATE: https://features.opensuse.org/313130 and one about improved subvolume handling: https://features.opensuse.org/314606 Going forward: feel free to add your requests to the openFATE database, ... So long - MgE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org