[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device na
bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names
Thu, 29 Dec 2011 16:02:08 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0
On 12/29/2011 02:09 PM, Jim Meyering wrote:
> On systems with recent kernel/tools, a symlink from /etc/mtab to
> /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone),
> you will see something like the following when running "df -hT":
> Filesystem Type Size Used
> Avail Use% Mounted on
> rootfs rootfs 11G 1.9G
> 8.0G 19% /
> /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G 1.9G
> 8.0G 19% /
BTW, this is the first mail I've gotten about 10363?
I guess this is the right thing to do.
I.E. have higher level paths in /proc/mounts, allowing
tools that require lower level paths to traverse the links
and pick the appropriate one.
The highest level path needs to be available to do this,
so I suppose this is appropriate in /proc/mounts,
even though it might not be the most appropriate for
human consumption, as can be seen above.
The patch looks good.
I guess "9" is the only questionable bit.
On my Fedora 16 system I have in /proc/mounts:
/dev/mapper/vg_tp1-lv_root ...... /
That's a fairly informative name, whereas the links further
resolve to a fairly generic:
Hmm, I was contemplating using the old wrap limit of 19,
but apart from not handling the above, using a width
is inconsistent. Perhaps it's better to always resolve?
I.E. always print the base device. It seems that one
can work back from this anyway:
$ findmnt --source /dev/dm-2
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/vg_tp1-lv_root ext4 rw,relatime,...