df -i shows 0 inodes 0 used 0 free on 4.4.0-36-generic Ubuntu 14 - Bug or not?

df -i shows 0 inodes 0 used 0 free on 4.4.0-36-generic Ubuntu 14 - Bug or not?

[GWB]

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?  I ask because root (/dev/sdc3) began to
display the error message "no space left on device", which was
eventually cured by deleting old snapshots then btrfs fi sync and
btrfs balance.  fi show and fi df show space, even when df -i shows 0
inodes:

sudo btrfs fi show /
...
Label: none  uuid: 9acdb642-d743-4c2a-a59f-811022c2a2b0
        Total devices 1 FS bytes used 23.86GiB
        devid    1 size 60.00GiB used 42.03GiB path /dev/sdc3


 sudo btrfs fi df /
Data, single: total=37.00GiB, used=21.11GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=5.00GiB, used=2.75GiB
unknown, single: total=512.00MiB, used=0.00

Please excuse my inexperience here; I don't know how to use btrfs
commands to show inodes.  btrfs inspect-internal will reference an
inode as near as I can tell, but won't list the used and free inodes
("free" may not be the correct word here, given btrfs architecture).

Many Thanks,

Gordon

Machine Specs:

% uname -a
Linux Bon-E 4.4.0-36-generic #55~14.04.1-Ubuntu SMP Fri Aug 12
11:49:30 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

% btrfs --version
Btrfs v3.12

% sudo btrfs fi show
Label: none  uuid: 9acdb642-d743-4c2a-a59f-811022c2a2b0
        Total devices 1 FS bytes used 23.86GiB
        devid    1 size 60.00GiB used 42.03GiB path /dev/sdc3

%Label: vm0  uuid: 72539416-d30e-4a34-8b2d-b2369d1fb075
        Total devices 1 FS bytes used 349.96GiB
        devid    1 size 374.66GiB used 374.66GiB path /dev/sdc4

dmesg does not appear to show anything useful for btrfs or device, but
mount shows:

% mount | grep btrfs
/dev/sdc3 on / type btrfs (rw,ssd,subvol=@)
/dev/sdc3 on /home type btrfs (rw,ssd,subvol=@home)
/dev/sdc4 on /vm0 type btrfs (rw,ssd,space_cache,compress=lzo,subvol=@vm0)
/dev/sdc3 on /mnt/btrfs-root type btrfs (rw)

Re: df -i shows 0 inodes 0 used 0 free on 4.4.0-36-generic Ubuntu 14 - Bug or not?

[Duncan]

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 
context.

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 
well.

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

Re: df -i shows 0 inodes 0 used 0 free on 4.4.0-36-generic Ubuntu 14 - Bug or not?

[GWB]

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.

Gordon

On Thu, Sep 15, 2016 at 10:26 PM, Duncan <1i5t5.duncan@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
> context.
>
> 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
> well.
>
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html