Good to know, and thank you for the quick reply. That helps. I'm
running btrfs on root and one of the vm partitions, and zfs on the
user folders and other vm partitions, largely because Ubuntu (and
gentoo, redhat, etc.) has btrfs in the kernel, it's very well
integrated with the kernel, and it's uses less memory than zfs. /vm0
is pretty much full; after scrub and balance I get this:
$ sudo btrfs fi df /vm0
Data, single: total=354.64GiB, used=349.50GiB
System, single: total=32.00MiB, used=80.00KiB
Metadata, single: total=1.00GiB, used=413.69MiB
unknown, single: total=144.00MiB, used=0.00
Scrub and balance seems to do the trick for / as well, after deleting
snapshots. When we get to the newer userland tools, I'll try the
version with later userspace tools you suggested. btrfs works great
on Ubuntu 14 on root running on an mSata drive with apt-btrfs-snapshot
installed. Nothing wrong with ext4, but coming from Solaris and
FreeBSD I wanted a fs that I could snapshot and roll back in case an
upgrade did not work.
The Stallman quote is great. Oracle taught me that lesson the hard
way when it "branched" zfs after version 28 into new revisions that
were incompatible with the OpenSolaris (and zfs linux) revisions going
forward. "zpool upgrade" on Solaris 11 makes the pool incompatible
with OpenSolaris and zfs-on-linux distros.
On Thu, Sep 15, 2016 at 10:26 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> GWB posted on Thu, 15 Sep 2016 18:58:24 -0500 as excerpted:
>> I don't expect accurate data on a btrfs file system when using df, but
>> after upgrading to kernel 4.4.0 I get the following:
>> $ df -i ...
>> /dev/sdc3 0 0 0 - /home
>> /dev/sdc4 0 0 0 - /vm0 ...
>> Where /dev/sdc3 and /dev/sdc4 are btrfs filesystems.
>> So is this a bug or not?
> Not a bug.
> Btrfs uses inodes, but unlike ext*, it creates them dynamically as-
> needed, so showing inodes used vs. free simply makes no sense in btrfs
> Now btrfs /does/ track data and metadata separately, creating chunks of
> each type, and it /is/ possible to have all otherwise free space already
> allocated to chunks of one type or the other and then run out of space in
> the one type of chunk while there's plenty of space in the other type of
> chunk, but that's quite a different concept, and btrfs fi usage (tho your
> v3.14 btrfs-progs will be too old for usage) or btrfs fi df coupled with
> btrfs fi show (the old way to get the same info), gives the information
> for that.
> And in fact, the btrfs fi show for vm0 says 374.66 GiB size and used, so
> indeed, all space on that one is allocated. Unfortunately you don't post
> the btrfs fi df for that one, so we can't tell where all that allocated
> space is going and whether it's actually used, but it's all allocated.
> You probably want to run a balance to get back some unallocated space.
> Meanwhile, your kernel is 4.4.x LTS series so not bad there, but your
> userspace is extremely old, 3.12, making support a bit hard as some of
> the commands have changed (btrfs fi usage, for one, and I think the
> checker was still btrfsck in 3.12, while in current btrfs-progs, it's
> btrfs check). I'd suggest updating that to at least something around the
> 4.4 level to match the kernel, tho you can upgrade to the latest 4.7.2
> (don't try 4.6 or 4.7 previous to 4.7.2, or don't btrfs check --repair if
> you do, as there's a bug with it in those versions that's fixed in 4.7.2)
> if you like, as newer userspace is designed to work with older kernels as
> Besides which, while old btrfs userspace isn't a big deal (other than
> translating back and forth between old style and new style commands) when
> your filesystems are running pretty much correctly, as in that case all
> userspace is doing in most cases is calling the kernel to do the real
> work anyway, it becomes a much bigger deal when something goes wrong,
> because it's userspace code that's executing with btrfs check or btrfs
> restore, and newer userspace knows about and can fix a LOT more problems
> than the really ancient 3.12.
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html