![](https://seccdn.libravatar.org/avatar/cabdbf4d350ab6a15265803acab1634d.jpg?s=120&d=mm&r=g)
Greg Freemyer said the following on 10/02/2013 12:08 PM:
On Wed, Oct 2, 2013 at 9:34 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
I've never heard of that, can you give references please?
As Carlos said the whole thread is worth reading: http://markmail.org/message/b5zmpqluenaq4fi5
The bug in question for failed RPM install is: https://bugzilla.novell.com/show_bug.cgi?id=835695
I don't know about you, but it seems very strange that a filesystem has a feature that has to be "enabled" before ImageMagick's rpm can be installed. It looks like openSUSE is considering that feature stable enough to enable it by default for 13.1, but I doubt 12.3 ever gets that mount option by default.
I'm thinking that some people involved in this thread haven't paid attention. I've certainly installed ImageMagic * on BtrFS * without having to adjust the parameters but as Greg goes on to say
Here's a 4-year thread that discusses it. The default limit is around 300 hardlinks in a single directory.
it strikes me as strange that a package needs to set up more than 300 hard links in a single directory.
Note: you can use btrfstune to enable the relatively new extrefs feature.
I didn't know about that when I installed Imagemagick. Why didn't I have that problem? As I said, this was btrFS with 12.3, new drive. This is the 3.6 kernel here, not the 'its in 3.7 already' in the bug report.
The new extrefs feature solves that but at least for now is not a always available filesystem feature.
So why didn't it happen to me? Perhaps because I have this huge single BtrFS partition.
It's not a inode issue.
A short while ago we did have "an inode issue". A user was running net news and his system was saying no more space even though df reported much free space. It turened out he was using ext3 or 4 and formatted with defaults. Net news has lots of small files and needs a different inode-to-space ratio. Now you can't remount an ext FS and solve that one! This fixed ratio is a piece of idiocy that dates back to the V6/V7 days Why do I mention it here and now. because in my true 'context is everything' mode I pointed out that in a context where you don't know a b-tree Fs like reiserFS is a better solution. Dealing with network speeds write performance isn't critical, but dealing with many feeds and write-one/read-many read is. Of course YMMV, or "Context is Everything". So lets slag off on the extFS family as well since it has deficiencies. And its had them for longer than BtrFS has existed.
Also snapper and btrfs have negative interactions in 12.3 that can fill your disk prematurely if you have root or /usr on btrfs. If root is full I think you have to boot to rescue mode to delete excess snapshots when it happens.
NO! The reality is that snapper is configurable. Once, just once I thought my disk was filling, and saw that it was because snapper was taking backups every time I did a 'zypper up'. I can see how valuable this is in a corporate setting, it means I can back out of specific updates!
Fine, but this is my desktop and I don't need that and turned it off. You can too. RTFM. It helps to read the release notes and realise you are getting this and turn it off before you've accumulated about 28G of updates and start thinking WTF? is going on. Stupid me!
I believe there are 2 issues:
1) df used to show disk free and included the snapshots as part of freespace. That is simply wrong because df would show space, but you could not create files. Has it been fixed in 12.2 / 12.3 / 13.1? (I don't have btrfs on my laptop currently so I don't know.)
It must have been fixed. I was seeing 'df' reporting a 'nearly out of space' in this huge drive. When I looked in detail it was all under the root level snapshot. That's what made me look into the matter. I can't see why df would not report this space. It reports space taken by other dotted 'hidden' files. Now du is different.
2) snapper's default config keeps way too many snapshots in 12.3 and before. For 13.1 they are reducing the default number kept.
Again, that's configurable. - The snapshots are like with a database, you can do both before and after imaging. - The cleanup runs from a cron job and has a number of different strategies. - certain programs such as yast and zypper make snapshots when they change the system. I find this very important in a production setting, but pretty irrelevant on my desktop/laptop.
But this is an incredibly useful feature and filling up the file system is not restricted to BtrFS.
Here's a btrfs FALSE filesystem full bug that has not been resolved in 12.3:
https://bugzilla.novell.com/show_bug.cgi?id=828229
Note it started reporting full when only about 9 TB of the 17 TB had been written. This does not appear to be a snapshot issue, but some other btrfs kernel bug.
I can't reproduce that, the largest FS I can do is 2T.
Take a look at bugzilla:
https://bugzilla.novell.com/buglist.cgi?quicksearch=btrfs
24 open bugs related to btrfs.
And actually some of those are like this https://bugzilla.novell.com/show_bug.cgi?id=787082 BtrFS is showing up bugs elsewhere. Of course its BtrFS's "fault" that timing problems occur elsewhere</irony>
It might be usable by many for a lot of circumstances, but to say it is stable in 12.3 and before is just not accurate. And even if the kernel is deemed stable for 13.1, then there is the userspace tools that need updates to work well with btrfs underlying them.
Lets face it, the same generalizations can be made about a lot of things we use, not just Linux file systems. We occasionally have people turn up saying that they live by just one file system and its so glorious. Bah Humbug! Context is Everything. But back when, in the V6, V7 and SCO days when we had just the V7FS and the Berkeley Fast File System then fiddling with the calculations of how much space to devote to inodes at installation was a major pain. I remember doing the root and /usr/{lib,bin} measurements over and overand being so thankful than /home was introduced so I could lock down the "installed" part of the OS. We didn't have almost daily updates back then. You lived with bugs for a long time. PAIN PAIN PAIN.
Based on the factory thread I suspect btrfs will be made the default install filesystem for 13.2 and a raft of new bugs and fixes will be going into 13.2
Well that is one way to force the developers to work on it!
fyi: 13.1 has already been branched off of factory and factory has been at least to some extent unfrozen and is accepting updates destined for 13.2. Major changes are still not welcome in factory for now. I don't know if changing the default install filesystem would be acceptable now or not.
So, what kernel? 3.8? 3.10 Or 3.12 - http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDk -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org