<div dir="ltr"><div dir="ltr"><div>> it's not clear to me whether yi-yo is happy yet?</div><div><br></div><div>Finally got some time to thoroughly test the *enhanced* df! I'm pretty happy with the output now, where `df <filesystem>` shows more accurate results than that of coreutils for over-mounted filesystems, and `df -a` shows all mounts no matter what (best effort output), so I can use `df -a | grep <filesystem-ish>` to get a pretty good grasp of the system state.</div><div><br></div><div>I also spot another case where toybox diverge from coreutils, and I think in this case coreutils' output makes more sense:</div><div><br></div><div><font face="monospace">$ mkdir -p aaa bbb</font></div><div><font face="monospace">$ dd if=/dev/zero of=ext4fs.img bs=4k count=2000</font></div><div><font face="monospace">$ mkfs.ext4 ext4fs.img</font></div><div><font face="monospace">$ sudo mount ext4fs.img aaa</font></div><div><font face="monospace">$ sudo mount --bind aaa bbb</font></div><div><font face="monospace">$ df -a | grep loop0</font></div><div><font face="monospace">/dev/loop0 6721 76 6085 2% /external/toybox/aaa<br>/dev/loop0 6721 76 6085 2% /external/toybox/bbb<br></font></div><div><font face="monospace">$ ./toybox df -a | grep loop0</font></div><font face="monospace">/dev/loop0 6721 76 6085 2% /external/toybox/aaa<br>/dev/loop0 - - - - /external/toybox/bbb</font><br></div><div dir="ltr"><br></div><div>toybox `df -a` cannot tell "failed stat" and bind-mount apart, they look the same, "-". I think we should add this back, so we can show bind-mounts as duplicated lines (Since stat() didn't fail, we shouldn't show "-"):</div><div><font face="monospace"><br></font></div><div><font face="monospace">@@ -177,8 +177,10 @@ void df_main(void)<br> if (mt->stat.st_dev == mt2->stat.st_dev) {<br> // For --bind mounts, show earliest mount<br> if (!strcmp(mt->device, mt2->device)) {<br>- mt3->stat.st_dev = 0;<br>- mt3 = mt2;<br>+ if (!FLAG(a)) {<br>+ mt3->stat.st_dev = 0;<br>+ mt3 = mt2;<br>+ }<br> } else mt2->stat.st_dev = 0;<br> }<br> }</font><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 18, 2021 at 6:00 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/17/21 1:40 PM, enh wrote:<br>
> <br>
> <br>
> On Wed, Feb 17, 2021 at 10:54 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank" class="cremed">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank" class="cremed">rob@landley.net</a>>> wrote:<br>
> <br>
> On 2/16/21 3:24 PM, enh wrote:<br>
> > There's a problem where if we can't stat it, we can't tell which one<br>
> it is out<br>
> > of /proc/mounts because we can't match the device. And you can't do an<br>
> exact<br>
> > match on the filename because "df ." is a directory under the mount<br>
> point. I<br>
> > would have to add plumbing to xabspath() and then do a longest match<br>
> > fileunderdir(), which assumes that the /proc/mounts entry is always a<br>
> cannonical<br>
> > absolute path? (I _think_ that's true in current kernels but would<br>
> have to read<br>
> > the source)...<br>
> ><br>
> > is this a place where it would help if we switch from /proc/mounts to<br>
> > /proc/self/mountinfo?<br>
> <br>
> Maybe, but I need more bandwidth to stare at that than I have available right<br>
> now. (Look up when it showed up in the kernel,<br>
> <br>
> <br>
> it passes that test at least, or i wouldn't have mentioned it: Linux 2.6.26 :-)<br>
> <br>
> <br>
> find the Documentation file<br>
> explaining what the fields are, evaluate whether the new fields are useful,<br>
> <br>
> <br>
> for context, <a href="https://man7.org/linux/man-pages/man5/procfs.5.html" rel="noreferrer" target="_blank" class="cremed">https://man7.org/linux/man-pages/man5/procfs.5.html</a> mentions mount<br>
> and parent mount unique ids which is what i thought might be useful. there's a<br>
> ton of other stuff too, and links<br>
> to <a href="https://man7.org/linux/man-pages/man7/mount_namespaces.7.html" rel="noreferrer" target="_blank" class="cremed">https://man7.org/linux/man-pages/man7/mount_namespaces.7.html</a> to explain some<br>
> of it, which in turn -- despite being pretty long -- redirects readers<br>
> to Documentation/filesystems/sharedsubtree.txt for more!<br>
<br>
I meant<br>
<a href="https://github.com/torvalds/linux/blob/master/Documentation/filesystems/proc.rst#35-----procpidmountinfo---information-about-mounts" rel="noreferrer" target="_blank" class="cremed">https://github.com/torvalds/linux/blob/master/Documentation/filesystems/proc.rst#35-----procpidmountinfo---information-about-mounts</a><br>
but that's nice too.<br>
<br>
> so, yeah, there does seem to be a large can of worms here.<br>
<br>
Oh yeah. I historically know rather a lot of it, but would need to refresh...<br>
<br>
> figure out what impact if any this has on BSD or macos,<br>
> <br>
> they're already using completely different code, that already doesn't actually<br>
> work (it doesn't give the same results as the macOS df, and i haven't had chance<br>
> to look at why [since i don't know of anyone actually using it, and it's not in<br>
> macos_defconfig anyway]). i think it's fine to break macOS a bit more for now,<br>
> and i can worry about that later.<br>
<br>
Someday I hope to have bandwidth to reopen the bsd ps/top can of worms...<br>
<br>
> and then compare against<br>
> just _always_ doing the xabspath() string comparison and if that simplifies<br>
> anything while providing sufficient behavior, plus the test suite needs<br>
> updating...)<br>
> <br>
> it's not clear to me whether yi-yo is happy yet?<br>
<br>
There's a pending issue df on a /dev/node and st_rdev, I might need to dig into<br>
the kernel to see when rdev is set and when I can trust it to be zero, but I<br>
think one pass over everything where I return the first st_dev match (from end)<br>
unless there's an st_rdev match. So one pass over the list that caches the first<br>
st_dev hit and returns it at the end of there was no st_rdev match.<br>
<br>
Oh here, let me just do that... commit 9c7085f484db<br>
<br>
> for my debian (strictly <a href="https://en.wikipedia.org/wiki/GLinux" rel="noreferrer" target="_blank" class="cremed">https://en.wikipedia.org/wiki/GLinux</a>) desktop, the only<br>
> difference between ToT toybox and coreutils right now is:<br>
> <br>
> [coreutils]<br>
> /dev/mapper/glinux_20200515-root 425941416 120332512 283902564 30% /<br>
> <br>
> versus:<br>
> <br>
> [toybox]<br>
> /dev/dm-1 425941416 120333508 283901568 30% /<br>
> <br>
> which i think is the opposite --- toybox seems to have dereferenced a symlink<br>
> that coreutils _didn't_?<br>
<br>
That was the part I wasn't sure about with the absolute path matching stuff.<br>
(Nobody said that the fstab entries were absolute paths, you can have two device<br>
nodes with the same major:minor, there's those uuid aliases... what does the<br>
kernel do with this stuff? No idea, gotta test and dig...) That's why I didn't<br>
do it that way to begin with. :)<br>
<br>
> ~$ ls -l /dev/mapper/glinux_20200515-root<br>
> lrwxrwxrwx 1 root root 7 Feb 16 14:02 /dev/mapper/glinux_20200515-root -> ../dm-1<br>
> <br>
> removing the xabspath() that's in df.c right now makes toybox match coreutils.<br>
<br>
Thus confirming that the kernel does _not_ return an absolute path. (I remember<br>
there was a way mount could have the kernel return a _relative_ path, from a<br>
current directory it hadn't recorded, which was annoying...)<br>
<br>
I forget, can you --bind mount a symlink? (I know I tried it, I don't remember<br>
the result...)<br>
<br>
> (okay, there's one other difference --- coreutils says "-" rather than "0%" for<br>
> filesystems of size 0. so all the /sys or /proc stuff has "-" in the Use%<br>
> column, not "0%", while still showing 0 in the other columns [because it did<br>
> stat(), but stat() said that the fs was zero-sized, and that's a special case?].)<br>
> <br>
> happy to send a patch/patches for either/both of those...<br>
<br>
Sure, send the patch. But also ask "is matching coreutils exactly the right<br>
thing to do"? It would be so nice if there were meaningful standards...<br>
<br>
Implementing stuff is generally easy. Working out the design goals and<br>
ramifications thereof (and doing tests to illuminate the corner cases, and<br>
AUTOMATING those tests in the test suite) is where all the effort goes...<br>
<br>
Rob<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><table width="90%" border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:0px;font-family:"Times New Roman";max-width:348px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td style="padding:0px"><table border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:20px 0px 0px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td valign="top" style="padding:0px 20px 0px 0px;vertical-align:top;border-right:1px solid rgb(213,213,213)"><img src="https://i.imgur.com/eGpkLls.png" width="200" height="64"><br></td><td style="padding:0px 0px 0px 20px"><table border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:0px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:1px 0px 5px;font-size:13px;line-height:13px;color:rgb(56,58,53);font-weight:700">Yi-yo Chiang</td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 5px;font-size:11px;line-height:13px;color:rgb(56,58,53)">Software Engineer</td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 5px;font-size:11px;line-height:13px;color:rgb(56,58,53)"><a href="mailto:yochiang@google.com" target="_blank" class="cremed">yochiang@google.com</a></td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 3px;font-size:11px;line-height:13px;color:rgb(3,112,248)"></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table></div></div></div>