[Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

[enh]

On Wed, Feb 17, 2021 at 10:54 AM Rob Landley <rob at landley.net> wrote:

> On 2/16/21 3:24 PM, enh wrote:
> >     There's a problem where if we can't stat it, we can't tell which one
> it is out
> >     of /proc/mounts because we can't match the device. And you can't do
> an exact
> >     match on the filename because "df ." is a directory under the mount
> point. I
> >     would have to add plumbing to xabspath() and then do a longest match
> >     fileunderdir(), which assumes that the /proc/mounts entry is always
> a cannonical
> >     absolute path? (I _think_ that's true in current kernels but would
> have to read
> >     the source)...
> >
> > is this a place where it would help if we switch from /proc/mounts to
> > /proc/self/mountinfo?
>
> Maybe, but I need more bandwidth to stare at that than I have available
> right
> now. (Look up when it showed up in the kernel,


it passes that test at least, or i wouldn't have mentioned it: Linux 2.6.26
:-)


> find the Documentation file
> explaining what the fields are, evaluate whether the new fields are useful,
>

for context, https://man7.org/linux/man-pages/man5/procfs.5.html mentions
mount and parent mount unique ids which is what i thought might be useful.
there's a ton of other stuff too, and links to
https://man7.org/linux/man-pages/man7/mount_namespaces.7.html to explain
some of it, which in turn -- despite being pretty long -- redirects readers
to Documentation/filesystems/sharedsubtree.txt for more!

so, yeah, there does seem to be a large can of worms here.


> figure out what impact if any this has on BSD or macos,


they're already using completely different code, that already doesn't
actually work (it doesn't give the same results as the macOS df, and i
haven't had chance to look at why [since i don't know of anyone actually
using it, and it's not in macos_defconfig anyway]). i think it's fine to
break macOS a bit more for now, and i can worry about that later.


> and then compare against
> just _always_ doing the xabspath() string comparison and if that simplifies
> anything while providing sufficient behavior, plus the test suite needs
> updating...)
>

it's not clear to me whether yi-yo is happy yet?

for my debian (strictly https://en.wikipedia.org/wiki/GLinux) desktop, the
only difference between ToT toybox and coreutils right now is:

[coreutils]
/dev/mapper/glinux_20200515-root 425941416 120332512 283902564  30% /

versus:

[toybox]
/dev/dm-1      425941416 120333508 283901568  30% /

which i think is the opposite --- toybox seems to have dereferenced a
symlink that coreutils _didn't_?

~$ ls -l /dev/mapper/glinux_20200515-root
lrwxrwxrwx 1 root root 7 Feb 16 14:02 /dev/mapper/glinux_20200515-root ->
../dm-1

removing the xabspath() that's in df.c right now makes toybox match
coreutils.

(okay, there's one other difference --- coreutils says "-" rather than "0%"
for filesystems of size 0. so all the /sys or /proc stuff has "-" in the
Use% column, not "0%", while still showing 0 in the other columns [because
it did stat(), but stat() said that the fs was zero-sized, and that's a
special case?].)

happy to send a patch/patches for either/both of those...

Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210217/dd2caf57/attachment.html>