On Thu, Jan 10, 2013 at 11:07:45AM +0100, Karel Zak wrote:
> On Tue, Jan 08, 2013 at 10:44:43AM +0000, Roger Leigh wrote:
> > Options like _netdev, comment= etc. are currently just ignored by
> > mount AFAICS. It would however be quite useful if they could be
> > preserved in e.g. utab if possible so that you can use this to
> > label mounts so that you can query for the information later using
> > e.g. mount or findmnt. Is this something which might be possible
> > to add if it's not already possible?
>
> The goal is to minimize number of situations when anything about
> mountpoints is maintained in userspace. It's usually too tricky to
> keep the userspace information synchronized with in-kernel
> information (imagine things like namespaces, sandboxes, ...).
This is what I understood, but thanks for the clarification here.
> > It turned out (at least in Debian) that some users were using the
> > "bind" option to track which filesystems were to be e.g. backed up,
> > space usage checked etc. (or not). With the switch to /proc/mounts
> > this information has been lost. While using the bind option to do
> > this is debatable, I was looking for a better and more robust
> > solution to their problem, and being able to attach comments to
> > the mounts seemed like it would fit in with the existing tools
> > if they could be stored.
>
> Would be possible to improve the backup scripts to maintain
> information about *filesystems* in userspace and address the
> information by filesystem UUIDs? Something like
>
> /var/log/backup-info/<UUID>/item{A,B,C}
>
> the UUID is stable, you will not affected by things like namespaces,
> umount/mount/move/... operations. The info will be completely
> independent on mountpoints and found the filesystem in the findmnt(8)
> or lsblk(8) output by UUID is pretty simple.
I already recommended this very approach. I just wanted to
bring it up here due to the lack of the bind option in the
/proc/mounts|mount output having some effect on breaking
existing applications which relied upon it, and this then
causing work in rewriting such applications. The reasons for
this changing are totally understandable though.
Thanks again,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
