Btrfs Finally Has A Concise Status Page

[starshipeleven]

My only disappointment with btrfs is that it still doesn't support native file encryption.

On the mailing list someone posted a patch for kernel 4.7 about adding encryption. this is the patch: https://github.com/0day-ci/linux/com...05dc0078a63651

[pal666]

Read comment #10. BCacheFS does indeed appear to be what we need. I hope it succeeds.

what makes you think i didn't read it? bcachefs indead appears to be "btrfs is not finished, so let's start new thing from scratch". you are free to hope for any improbable thing

[pal666]

They didn't. Shut up until you read up.

fuck off, btrfs also didn't implement whole kernel. they did start new filesystem. btw why do you call one person "they"?

[pal666]

I'll defer to what Overstreet says about it. I believe

lol, i see new religion here

[pal666]

You're making a gross assumption that because some projects are mismanaged

you are making a gross assumption that when one person claims he will solve hard problem by launching thunderbolts from eyes, his claim is true

[GizmoChicken]

On the mailing list someone posted a patch for kernel 4.7 about adding encryption. this is the patch: https://github.com/0day-ci/linux/com...05dc0078a63651

Thanks for pointing this out. Great to see that they're working on this.

[finite9]

when btrfs came out, I got a sinking feeling in my stomach, because as an Oracle DBA, im used to extents in datafiles, so when I found out that btrfs was based on extents, I was initially negative to it, because it felt like Chris, working for Oracle, was trying to showhorn their idea of db datafile management into a filesystem model. I have no idea really if this is a good or bad thing, but it would be interesting to hear from someone who can say more about it with authority.

In practice, two things that feel unneccessarily complicated to me, are the use of rolling back snapshots of the OS in conjunction with yum/dnf, and how btrfs determine free space on the filesystem:

For the first, I just never could get it to work, and I have yet to find a howto on the internet that shows concidely how this feature is supposed to work in practice! Im a technical person, and maybe im being dense, but ill be f***ed if I can figure it out--i run dnf update, my system goes bad and I want to rollback to previous state using btrfs snapshot.

wrt to the second gripe, I dont really buy their excuses for why it's so hard to figure out free space in the filesystem, and that all previous tools on Linux completely fail to function with this. 'df -h' should apparently display _total_ usage (yes even the metadata), whereas 'btrfs filesystem df' should show the breakdown of data/system/metadata, but on my system this doesn't correspond 100%, there is a discrepancy of 1GB between the two tools, and i have previously gotten 'no space left on device' errors and everything looks hunky dorey with btrfs filesystem df and df-h, i.e. several GiBs of free space according to both tools.


you know when you get half way through a mindless rant and realise you've just talked shit for 10 minutes? Well that's where I am right now, but i'll still post so I can be shot down and told that im being an idiot because maybe I might learn somthing

[xeekei]

fuck off, btrfs also didn't implement whole kernel. they did start new filesystem.

BCacheFS is more like a retrofit than a 'start froms scratch', especially if you compare it to Btrfs.

[GreatEmerald]

In practice, two things that feel unneccessarily complicated to me, are the use of rolling back snapshots of the OS in conjunction with yum/dnf, and how btrfs determine free space on the filesystem:

For the first, I just never could get it to work, and I have yet to find a howto on the internet that shows concidely how this feature is supposed to work in practice! Im a technical person, and maybe im being dense, but ill be f***ed if I can figure it out--i run dnf update, my system goes bad and I want to rollback to previous state using btrfs snapshot.

I don't know about Fedora, but the way it works on openSUSE (they developed Snapper) is that before doing anything with packages snapper makes a "pre" snapshot, and afterwards it makes a "post" snapshot, so you can easily see the differences. Then if something gets messed up you use Snapper again to restore individual files. If something goes really wrong and you can't even boot, you instead boot into a previous snapshot (Snapper has GRUB integration and you get a boot-time choice of snapshots to boot into).

The lower-level details are also all explained in detail on the Btrfs wiki, sysadmin guide.

wrt to the second gripe, I dont really buy their excuses for why it's so hard to figure out free space in the filesystem, and that all previous tools on Linux completely fail to function with this. 'df -h' should apparently display _total_ usage (yes even the metadata), whereas 'btrfs filesystem df' should show the breakdown of data/system/metadata, but on my system this doesn't correspond 100%, there is a discrepancy of 1GB between the two tools, and i have previously gotten 'no space left on device' errors and everything looks hunky dorey with btrfs filesystem df and df-h, i.e. several GiBs of free space according to both tools.

If it wasn't hard, you wouldn't be having those problems, now would you?
Also, btrfs filesystem usage (the new tool to check for free space, you can mostly forget fi df) lists unallocated space, which is what is what you want to know here. Even if there is a lot of "free space", if it's allocated, you will get ENOSPC. You have to rebalance chunks in order for space that is technically free but still allocated to get deallocated. They are already working on an implementation that would do that automatically.

[Anvil]

uhhhhhh..... No.

why do you say No? i cant see Redhat supporting BTRFS as default