Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

df: rows appear in different order on each execution, but shouldn't #3086

Closed
jfinkels opened this issue Feb 6, 2022 · 3 comments · Fixed by #3126
Closed

df: rows appear in different order on each execution, but shouldn't #3086

jfinkels opened this issue Feb 6, 2022 · 3 comments · Fixed by #3126
Labels

Comments

@jfinkels
Copy link
Collaborator

jfinkels commented Feb 6, 2022

Running df with no other arguments results in a different order of rows on each execution. In contrast, the GNU version of df seems to produce rows in the same order on each execution.

GNU df:

$ df | head -n 5
Filesystem                1K-blocks     Used Available Use% Mounted on
udev                        3858028        0   3858028   0% /dev
tmpfs                        782624     2112    780512   1% /run
/dev/mapper/vgubuntu-root 242791844 93491652 136897300  41% /
tmpfs                       3913120        0   3913120   0% /dev/shm
$ df | head -n 5
Filesystem                1K-blocks     Used Available Use% Mounted on
udev                        3858028        0   3858028   0% /dev
tmpfs                        782624     2112    780512   1% /run
/dev/mapper/vgubuntu-root 242791844 93491652 136897300  41% /
tmpfs                       3913120        0   3913120   0% /dev/shm

uutils df:

$ ./target/debug/df | head -n 5
Filesystem          1k-blocks         Used    Available  Use% Mounted on       
/dev/loop5           56885248     56885248            0  100% /snap/snap-store/558
/dev/nvme0n1p1      535805952     32583680    503222272    6% /boot/efi       
/dev/loop1           58327040     58327040            0  100% /snap/core18/2284
tmpfs               801406976        73728    801333248    0% /run/user/1000  
$ ./target/debug/df | head -n 5
Filesystem          1k-blocks         Used    Available  Use% Mounted on       
/dev/loop4           65011712     65011712            0  100% /snap/core20/1270
tmpfs              4007034880            0   4007034880    0% /sys/fs/cgroup  
tmpfs              4007034880            0   4007034880    0% /dev/shm        
/dev/loop0           58195968     58195968            0  100% /snap/core18/2253
@tertsdiepraam
Copy link
Member

Do you have any idea what GNU's order is based on?

@jfinkels
Copy link
Collaborator Author

jfinkels commented Feb 7, 2022

On my Linux machine, It seems like it is based on the order given in /proc/mounts or /etc/mtab. The uucore::fsext::read_fs_list() function reads those:

let (file_name, f) = File::open(LINUX_MOUNTINFO)
.map(|f| (LINUX_MOUNTINFO, f))
.or_else(|_| File::open(LINUX_MTAB).map(|f| (LINUX_MTAB, f)))
.expect("failed to find mount list files");
but the df::filter_mount_list() collects them into a HashMap:
HashMap::<String, Cell<MountInfo>>::new(),
so the order is lost.

@tertsdiepraam
Copy link
Member

Good to know! Thanks!

jfinkels added a commit to jfinkels/coreutils that referenced this issue Feb 13, 2022
Change the `filter_mount_list()` function so that it always produces
the same order of `MountInfo` objects. This change ultimately results
in `df` printing its table of filesystems in the same order on each
execution. Previously, the table was in an arbitrary order because the
`MountInfo` objects were read from a `HashMap`.

Fixes uutils#3086.
jfinkels added a commit to jfinkels/coreutils that referenced this issue Feb 13, 2022
Change the `filter_mount_list()` function so that it always produces
the same order of `MountInfo` objects. This change ultimately results
in `df` printing its table of filesystems in the same order on each
execution. Previously, the table was in an arbitrary order because the
`MountInfo` objects were read from a `HashMap`.

Fixes uutils#3086.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants