Quoting H. Peter Anvin (hpa@xxxxxxxxx): > Al Viro wrote: > > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: > >> ... or, alternatively, add a subfield to the first field (which would > >> entail escaping whatever separator we choose): > >> > >> /dev/md6 /export ext3 rw,data=ordered 0 0 > >> /dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0 > >> /dev/md6:/users/bar /home/bar ext3 rw,data=ordered 0 0 > > > > Hell, no. The first field is in principle impossible to parse unless > > you know the fs type. > > > > How about making a new file with sane format? From the very > > beginning. E.g. mountpoint + ID + relative path + type + options, > > where ID uniquely identifies superblock (e.g. numeric st_dev) > > and backing device (if any) is sitting among the options... > > The more I'm thinking about this, I think it's simplest to just add > fields to the right of the existing /proc/*/mounts. Yes, the format is > ugly, and it will end up being uglier still, but it's also ugly to have > a bunch of different chunks of information formatted in different ways. Since we're defining the order "arbitrarily" in any case, I really don't think it's all that ugly. Are there any existing tools which would not be able to handle the extra fields? (suppose it's easiest to just add the fields, try a few distros, and see which balk) > So, the existing fields are: > > mnt_devname mnt_path filesystem_type options 0 0 > > ... and we'd want to add ... > > mnt_id propagation_info sb_dev path_to_fs_root > > As previously stated, in order to avoid having to expose kernel > addresses to userspace, I suggest we simply add a counter field to > struct vfsmount and use that for mnt_id. Agreed - even if it weren't frowned upon to expose the kernel addresses, it would just be much nicer to have easier to remember ids. Somehow with the kernel address, even with just a set of 5 of them printed in front of me it takes me 2 minutes to figure out which ones are the same... > I'm not all that up on what is needed for propagation_info. I presume > we want to be able to deduce the full mount lattice. One particularly I think Ram's existing patches just provided "PEER (next-peer-id)" or "SLAVE (master-id)". > important thing in my mind is to be able to distinguish overmounted > filesystems (which I think is possible in the current setup only by What exactly do you mean here? Do you mean information about stackable filesystems - i.e. ecryptfs, unionfs, etc? If so, maybe a last column which the fs itself can fill in with such information is the best way to go then? Ecryptfs would have just one pathname to fill in (the location of the encrypted dir), unionfs might have several (the full stack of unioned directories). > ordering -- the filesystem on top I believe will end up last in > /proc/mounts, but I don't know if there actually is anything that > enforces that.) Hmm, or do you actually mean that if i'd done mount --bind /tmp/a /tmp mount --bind /tmp/b /tmp mount --bind /tmp/c /tmp that you would want to see information about the first two mounts? -serge - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
