* About /etc/mtab and /proc/mounts @ 2003-02-19 11:21 DervishD 2003-02-26 9:18 ` Kasper Dupont 0 siblings, 1 reply; 56+ messages in thread From: DervishD @ 2003-02-19 11:21 UTC (permalink / raw) To: Linux-kernel Hi all :)) I would like to know if adding the bits of information that /etc/mtab has and /proc/mount doesn't needs a lot of work. The problem here is that /etc/mtab, although traditional, does not make sense in systems where /etc is mounted read-only. Usually, the only reason for mounting it read-write is the mtab... Well, nowadays is very usual to see systems where /etc/mtab is just a symlink to /proc/mounts, but then you lose some information. That is, you can live without that info, but if it can be easily added I think that it would worth the effort. Unfortunately, some of this information is obtained from /etc/fstab but IMHO the kernel has that info too in some table, I suppose... Well, if someone familiar with this part of the kernel gives me the information I think I can write the code for the 'extra' information ;)) I give an example of this extra information: in /etc/mtab we have: pts /dev/pts devpts rw,gid=5,mode=620 0 0 in /proc/mounts we have: pts /dev/pts devpts rw 0 0 Other filesystems, as tmpfs, has the size information, for example, etc... Thanks in advance. Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-19 11:21 About /etc/mtab and /proc/mounts DervishD @ 2003-02-26 9:18 ` Kasper Dupont 2003-02-26 10:26 ` Miquel van Smoorenburg ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: Kasper Dupont @ 2003-02-26 9:18 UTC (permalink / raw) To: DervishD; +Cc: Linux-kernel DervishD wrote: > > Hi all :)) > > I would like to know if adding the bits of information that > /etc/mtab has and /proc/mount doesn't needs a lot of work. The > problem here is that /etc/mtab, although traditional, does not make > sense in systems where /etc is mounted read-only. Usually, the only > reason for mounting it read-write is the mtab... We are also discussing that from time to time on c.o.l.d.system. You could take a look on the thread starting with <news:3E5A343D.186F3074@daimi.au.dk> I don't think you can put all the information from /etc/mtab into /proc/mounts without breaking compatibility. So perhaps a new /proc/mtab would be a better aproach? However some of the fields written to mtab by mount is not easilly known by the kernel, so perhaps we could have mount write them to /proc/mtab. A simpler solution, that does not require changes to the kernel would be to just move mtab to a more apropriate location. My suggestion would be to change it from /etc/mtab to /mtab.d/mtab. Then you could mount a tmpfs filesystem on /mtab.d. Or by making /mtab.d a symlink, you can get the mtab file whereever you want, including /etc. > > Well, nowadays is very usual to see systems where /etc/mtab is > just a symlink to /proc/mounts, but then you lose some information. > That is, you can live without that info, but if it can be easily > added I think that it would worth the effort. I agree with that. Some of it may be easy, but not all of it. > > Unfortunately, some of this information is obtained from > /etc/fstab but IMHO the kernel has that info too in some table, I > suppose... > > Well, if someone familiar with this part of the kernel gives me > the information I think I can write the code for the 'extra' > information ;)) > > I give an example of this extra information: > > in /etc/mtab we have: > pts /dev/pts devpts rw,gid=5,mode=620 0 0 > > in /proc/mounts we have: > pts /dev/pts devpts rw 0 0 > > Other filesystems, as tmpfs, has the size information, for > example, etc... Some more interesting cases are loopback mounts and bind mounts, in which case the device field is completely different. But the filesystem specific options are not trivial either. The fact that you can use a remount to change some of the options but not all of them means that only the filesystem itself can tell you what exactly the options are right now. (And since I remember remount bugs in tmpfs in early 2.4 kernels, it is not going to get easier to put more requirements on the filesystem.) -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 9:18 ` Kasper Dupont @ 2003-02-26 10:26 ` Miquel van Smoorenburg 2003-02-26 11:00 ` Olaf Dietsche 2003-02-27 4:14 ` Miles Bader 2003-03-02 12:51 ` DervishD 2 siblings, 1 reply; 56+ messages in thread From: Miquel van Smoorenburg @ 2003-02-26 10:26 UTC (permalink / raw) To: linux-kernel In article <3E5C8682.F5929A04@daimi.au.dk>, Kasper Dupont <kasperd@daimi.au.dk> wrote: >A simpler solution, that does not require changes to the kernel >would be to just move mtab to a more apropriate location. My >suggestion would be to change it from /etc/mtab to /mtab.d/mtab. >Then you could mount a tmpfs filesystem on /mtab.d. Or by making >/mtab.d a symlink, you can get the mtab file whereever you want, >including /etc. /dev/shm ? Supposed to be there on many systems anyway. Fix 'mount' and 'umount' so that if they see /etc/mtab is a symlink, they follow it and create the temp files etc in the destination directory of the link instead of in /etc. Then ln -sf /dev/shm/mtab /etc/mtab et voila I've been thinking of doing this for Debian. Mike. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job -- Douglas Adams. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 10:26 ` Miquel van Smoorenburg @ 2003-02-26 11:00 ` Olaf Dietsche 2003-02-26 11:14 ` Måns Rullgård 0 siblings, 1 reply; 56+ messages in thread From: Olaf Dietsche @ 2003-02-26 11:00 UTC (permalink / raw) To: Miquel van Smoorenburg; +Cc: linux-kernel miquels@cistron-office.nl (Miquel van Smoorenburg) writes: > In article <3E5C8682.F5929A04@daimi.au.dk>, > Kasper Dupont <kasperd@daimi.au.dk> wrote: >>A simpler solution, that does not require changes to the kernel >>would be to just move mtab to a more apropriate location. My >>suggestion would be to change it from /etc/mtab to /mtab.d/mtab. >>Then you could mount a tmpfs filesystem on /mtab.d. Or by making >>/mtab.d a symlink, you can get the mtab file whereever you want, >>including /etc. > > /dev/shm ? Supposed to be there on many systems anyway. Fix > 'mount' and 'umount' so that if they see /etc/mtab is a symlink, > they follow it and create the temp files etc in the destination > directory of the link instead of in /etc. Then > ln -sf /dev/shm/mtab /etc/mtab et voila I thought, this is what /var is for. So, /var/run, /var/lib/misc or /var/etc might be more appropriate? OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here. Regards, Olaf. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 11:00 ` Olaf Dietsche @ 2003-02-26 11:14 ` Måns Rullgård 2003-02-26 11:44 ` Kasper Dupont 2003-02-26 12:16 ` Olaf Dietsche 0 siblings, 2 replies; 56+ messages in thread From: Måns Rullgård @ 2003-02-26 11:14 UTC (permalink / raw) To: Olaf Dietsche; +Cc: Miquel van Smoorenburg, linux-kernel Olaf Dietsche <olaf.dietsche@t-online.de> writes: > >>A simpler solution, that does not require changes to the kernel > >>would be to just move mtab to a more apropriate location. My > >>suggestion would be to change it from /etc/mtab to /mtab.d/mtab. > >>Then you could mount a tmpfs filesystem on /mtab.d. Or by making > >>/mtab.d a symlink, you can get the mtab file whereever you want, > >>including /etc. > > > > /dev/shm ? Supposed to be there on many systems anyway. Fix > > 'mount' and 'umount' so that if they see /etc/mtab is a symlink, > > they follow it and create the temp files etc in the destination > > directory of the link instead of in /etc. Then > > ln -sf /dev/shm/mtab /etc/mtab et voila > > I thought, this is what /var is for. So, /var/run, /var/lib/misc or > /var/etc might be more appropriate? What if /var is mounted separately? > OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here. The only problem I have with that is that option 'user' is lost. This means that any user can mount /cdrom, but only root can unmount it. -- Måns Rullgård mru@users.sf.net ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 11:14 ` Måns Rullgård @ 2003-02-26 11:44 ` Kasper Dupont 2003-02-26 12:16 ` Olaf Dietsche 1 sibling, 0 replies; 56+ messages in thread From: Kasper Dupont @ 2003-02-26 11:44 UTC (permalink / raw) To: Måns Rullgård Cc: Olaf Dietsche, Miquel van Smoorenburg, linux-kernel Måns Rullgård wrote: > > Olaf Dietsche <olaf.dietsche@t-online.de> writes: > > > >>A simpler solution, that does not require changes to the kernel > > >>would be to just move mtab to a more apropriate location. My > > >>suggestion would be to change it from /etc/mtab to /mtab.d/mtab. > > >>Then you could mount a tmpfs filesystem on /mtab.d. Or by making > > >>/mtab.d a symlink, you can get the mtab file whereever you want, > > >>including /etc. > > > > > > /dev/shm ? Supposed to be there on many systems anyway. Fix > > > 'mount' and 'umount' so that if they see /etc/mtab is a symlink, > > > they follow it and create the temp files etc in the destination > > > directory of the link instead of in /etc. Then > > > ln -sf /dev/shm/mtab /etc/mtab et voila > > > > I thought, this is what /var is for. So, /var/run, /var/lib/misc or > > /var/etc might be more appropriate? > > What if /var is mounted separately? I agree with all of you. /dev/shm is widely available, and is a filesystem of the desired type. /var is intended for this kind of data, and /var/run seems intuitively the right location. But /dev as well as /var are often mountpoints. So to use those locations would introduce more mountpoints that will need special care early in the startup scripts. And mounting them before running fsck is a problem. All of those thoughts is what lead me to the suggestion of a new directory or symlink in the root. You can point it anywhere you want mtab. And you don't need to mount any filesystems before the symlink can be used. A symlink in the other direction would not work that well. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 11:14 ` Måns Rullgård 2003-02-26 11:44 ` Kasper Dupont @ 2003-02-26 12:16 ` Olaf Dietsche 2003-02-26 12:34 ` Måns Rullgård 1 sibling, 1 reply; 56+ messages in thread From: Olaf Dietsche @ 2003-02-26 12:16 UTC (permalink / raw) To: Måns Rullgård; +Cc: Miquel van Smoorenburg, linux-kernel mru@users.sourceforge.net (Måns Rullgård) writes: > Olaf Dietsche <olaf.dietsche@t-online.de> writes: > >> I thought, this is what /var is for. So, /var/run, /var/lib/misc or >> /var/etc might be more appropriate? > > What if /var is mounted separately? I didn't think of this, even though I have it separately on my machine. >> OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here. > > The only problem I have with that is that option 'user' is lost. This > means that any user can mount /cdrom, but only root can unmount it. The 'user' option is in /etc/fstab, so this is not a problem. I can mount _and_ umount /cdrom as a simple user. Regards, Olaf. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 12:16 ` Olaf Dietsche @ 2003-02-26 12:34 ` Måns Rullgård 2003-02-26 13:39 ` Olaf Dietsche 0 siblings, 1 reply; 56+ messages in thread From: Måns Rullgård @ 2003-02-26 12:34 UTC (permalink / raw) To: Olaf Dietsche Cc: Måns Rullgård, Miquel van Smoorenburg, linux-kernel Olaf Dietsche <olaf.dietsche@t-online.de> writes: > >> I thought, this is what /var is for. So, /var/run, /var/lib/misc or > >> /var/etc might be more appropriate? > > > > What if /var is mounted separately? > > I didn't think of this, even though I have it separately on my > machine. > > >> OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here. > > > > The only problem I have with that is that option 'user' is lost. This > > means that any user can mount /cdrom, but only root can unmount it. > > The 'user' option is in /etc/fstab, so this is not a problem. I can > mount _and_ umount /cdrom as a simple user. It's strange if you can. My mount (fairly recent) looks in fstab to determine whether a user should be allowed to mount a device. However, when unmounting it checks /etc/mtab to make sure it was you who mounted it in the first place, making it impossible to unmount someone else's cdrom. If you use the 'users' (note the 's') option instead any user can mount or unmount the device at any time, mtab being ignored. -- Måns Rullgård mru@users.sf.net ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 12:34 ` Måns Rullgård @ 2003-02-26 13:39 ` Olaf Dietsche 2003-02-26 13:54 ` Måns Rullgård 0 siblings, 1 reply; 56+ messages in thread From: Olaf Dietsche @ 2003-02-26 13:39 UTC (permalink / raw) To: Måns Rullgård; +Cc: Miquel van Smoorenburg, linux-kernel mru@users.sourceforge.net (Måns Rullgård) writes: > Olaf Dietsche <olaf.dietsche@t-online.de> writes: > >> The 'user' option is in /etc/fstab, so this is not a problem. I can >> mount _and_ umount /cdrom as a simple user. > > It's strange if you can. My mount (fairly recent) looks in fstab to > determine whether a user should be allowed to mount a device. > However, when unmounting it checks /etc/mtab to make sure it was you > who mounted it in the first place, making it impossible to unmount > someone else's cdrom. If you use the 'users' (note the 's') option > instead any user can mount or unmount the device at any time, mtab > being ignored. I just verified it. I and anybody else can mount and umount /cdrom. If I mounted /cdrom, someone else can umount it. $ mount -V mount: mount-2.11n $ grep user /etc/fstab /dev/hdb/0 /cdrom iso9660 defaults,ro,unhide,user,noauto,noexec,nosuid 0 2 $ ls -l /etc/mtab lrwxrwxrwx 1 root root 12 2002-09-22 02:58 /etc/mtab -> /proc/mounts When /etc/mtab is a regular file, it works as you described. Regards, Olaf. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 13:39 ` Olaf Dietsche @ 2003-02-26 13:54 ` Måns Rullgård 2003-02-26 14:23 ` Olaf Dietsche 0 siblings, 1 reply; 56+ messages in thread From: Måns Rullgård @ 2003-02-26 13:54 UTC (permalink / raw) To: Olaf Dietsche Cc: Måns Rullgård, Miquel van Smoorenburg, linux-kernel Olaf Dietsche <olaf.dietsche@t-online.de> writes: > >> The 'user' option is in /etc/fstab, so this is not a problem. I can > >> mount _and_ umount /cdrom as a simple user. > > > > It's strange if you can. My mount (fairly recent) looks in fstab to > > determine whether a user should be allowed to mount a device. > > However, when unmounting it checks /etc/mtab to make sure it was you > > who mounted it in the first place, making it impossible to unmount > > someone else's cdrom. If you use the 'users' (note the 's') option > > instead any user can mount or unmount the device at any time, mtab > > being ignored. > > I just verified it. I and anybody else can mount and umount /cdrom. If > I mounted /cdrom, someone else can umount it. > > $ mount -V > mount: mount-2.11n > > $ grep user /etc/fstab > /dev/hdb/0 /cdrom iso9660 defaults,ro,unhide,user,noauto,noexec,nosuid 0 2 > > $ ls -l /etc/mtab > lrwxrwxrwx 1 root root 12 2002-09-22 02:58 /etc/mtab -> /proc/mounts > > When /etc/mtab is a regular file, it works as you described. What does your /proc/mounts look like when the cdrom is mounted? Are you using a standard mount, or something hacked up by RH or others? -- Måns Rullgård mru@users.sf.net ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 13:54 ` Måns Rullgård @ 2003-02-26 14:23 ` Olaf Dietsche 0 siblings, 0 replies; 56+ messages in thread From: Olaf Dietsche @ 2003-02-26 14:23 UTC (permalink / raw) To: Måns Rullgård; +Cc: linux-kernel mru@users.sourceforge.net (Måns Rullgård) writes: > What does your /proc/mounts look like when the cdrom is mounted? Are $ grep cdrom /proc/mounts /dev/hdb/0 /cdrom iso9660 ro,nosuid,nodev,noexec 0 0 > you using a standard mount, or something hacked up by RH or others? Debian unstable, but I didn't upgrade mount for quite some time. $ dpkg -l mount ii mount 2.11n-4 Tools for mounting and manipulating filesystems. Regards, Olaf. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 9:18 ` Kasper Dupont 2003-02-26 10:26 ` Miquel van Smoorenburg @ 2003-02-27 4:14 ` Miles Bader 2003-02-27 6:40 ` Kasper Dupont 2003-03-02 12:53 ` DervishD 2003-03-02 12:51 ` DervishD 2 siblings, 2 replies; 56+ messages in thread From: Miles Bader @ 2003-02-27 4:14 UTC (permalink / raw) To: Kasper Dupont; +Cc: DervishD, Linux-kernel Kasper Dupont <kasperd@daimi.au.dk> writes: > I don't think you can put all the information from /etc/mtab > into /proc/mounts without breaking compatibility. Why? Since the option syntax is regular, presumably programs simply ignore options they don't understand. No? > My suggestion would be to change it from /etc/mtab to /mtab.d/mtab. Please, no. don't pollute the root (_especially_ with little one-use directories like that). /var is clearly the right place for this; if /var isn't mounted initially, I'd suggest that mount should simply not update any file at that point, and the init-script that mounts /var can be responsible from propagating information from /proc/mounts to /var/whatever. -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 4:14 ` Miles Bader @ 2003-02-27 6:40 ` Kasper Dupont 2003-02-27 7:03 ` Joseph Wenninger ` (3 more replies) 2003-03-02 12:53 ` DervishD 1 sibling, 4 replies; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 6:40 UTC (permalink / raw) To: Miles Bader; +Cc: DervishD, Linux-kernel Miles Bader wrote: > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > I don't think you can put all the information from /etc/mtab > > into /proc/mounts without breaking compatibility. > > Why? Since the option syntax is regular, presumably programs simply > ignore options they don't understand. No? It is mostly the device field I had in mind. > > > My suggestion would be to change it from /etc/mtab to /mtab.d/mtab. > > Please, no. don't pollute the root (_especially_ with little one-use > directories like that). Unfortunately it is the best solution I can come up with. > > /var is clearly the right place for this; Is it? > if /var isn't mounted > initially, I'd suggest that mount should simply not update any file at > that point, and the init-script that mounts /var can be responsible from > propagating information from /proc/mounts to /var/whatever. Would you fsck /var while it is mounted? I think part of the problem is that /var is used for both files we want to keep across reboot, and files we do not want to keep across reboot. There are cases where it is undesirable to have mtab in /var, but if mount expect to find mtab somewhere under /var, we can't even use a symlink to get it out of there, because /var needs to be mounted before the symlink can be followed. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 6:40 ` Kasper Dupont @ 2003-02-27 7:03 ` Joseph Wenninger 2003-02-27 8:28 ` Kasper Dupont 2003-02-27 7:06 ` Miles Bader ` (2 subsequent siblings) 3 siblings, 1 reply; 56+ messages in thread From: Joseph Wenninger @ 2003-02-27 7:03 UTC (permalink / raw) To: Kasper Dupont; +Cc: Miles Bader, DervishD, Linux-kernel Hi Am Don, 2003-02-27 um 07.40 schrieb Kasper Dupont: > Miles Bader wrote: > > > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > I don't think you can put all the information from /etc/mtab > > > into /proc/mounts without breaking compatibility. > > For KDE 3.1 I've written a mount watcher, which checks the modification time of the /etc/mtab to recognize mount/unmount activity, which broke for linux from scratch( for now, they have updated there install instructions), because they linked to /proc/mounts, which doesn't seem to support mtime. If the mtab is really completly removed, is there something else I can use to track mount activities from userspace ? I don't want to retrieve the whole mounted list all the time and compare each entry to my internally stored list, just to find out that nothing has changed anyways. Kind regards Joseph Wenninger ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 7:03 ` Joseph Wenninger @ 2003-02-27 8:28 ` Kasper Dupont 2003-03-05 0:03 ` Jamie Lokier 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 8:28 UTC (permalink / raw) To: Joseph Wenninger; +Cc: Miles Bader, DervishD, Linux-kernel Joseph Wenninger wrote: > > Hi > > Am Don, 2003-02-27 um 07.40 schrieb Kasper Dupont: > > Miles Bader wrote: > > > > > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > > I don't think you can put all the information from /etc/mtab > > > > into /proc/mounts without breaking compatibility. > > > > > For KDE 3.1 I've written a mount watcher, which checks the modification > time of the /etc/mtab to recognize mount/unmount activity, which broke > for linux from scratch( for now, they have updated there install > instructions), because they linked to /proc/mounts, which doesn't seem > to support mtime. It seems the mtime of anything under /proc simply gives the current time. Would that be hard to change? And would anything break if /proc/mounts gave the time of the last change? It shouldn't be a major problem to record the time of the last sucessfull mount, remount, or unmount. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 8:28 ` Kasper Dupont @ 2003-03-05 0:03 ` Jamie Lokier 0 siblings, 0 replies; 56+ messages in thread From: Jamie Lokier @ 2003-03-05 0:03 UTC (permalink / raw) To: Kasper Dupont; +Cc: Joseph Wenninger, Miles Bader, DervishD, Linux-kernel Kasper Dupont wrote: > > For KDE 3.1 I've written a mount watcher, which checks the modification > > time of the /etc/mtab to recognize mount/unmount activity, which broke > > for linux from scratch( for now, they have updated there install > > instructions), because they linked to /proc/mounts, which doesn't seem > > to support mtime. > > It seems the mtime of anything under /proc simply gives the current time. > Would that be hard to change? And would anything break if /proc/mounts > gave the time of the last change? It shouldn't be a major problem to > record the time of the last sucessfull mount, remount, or unmount. It would be much better if it were possible to use fcntl(?,F_NOTIFY,...) to monitor the contents of /proc/mounts. (It would have to be in a subdirectory of its own for this). -- Jamie ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 6:40 ` Kasper Dupont 2003-02-27 7:03 ` Joseph Wenninger @ 2003-02-27 7:06 ` Miles Bader 2003-02-27 8:25 ` Kasper Dupont 2003-02-27 7:07 ` Joseph Wenninger 2003-02-27 7:08 ` Dominik Kubla 3 siblings, 1 reply; 56+ messages in thread From: Miles Bader @ 2003-02-27 7:06 UTC (permalink / raw) To: Kasper Dupont; +Cc: DervishD, Linux-kernel Kasper Dupont <kasperd@daimi.au.dk> writes: > > /var is clearly the right place for this; > > Is it? Yes. On some systems, /var and /tmp are the _only_ read-write filesystems. > > if /var isn't mounted initially, I'd suggest that mount should > > simply not update any file at that point, and the init-script that > > mounts /var can be responsible from propagating information from > > /proc/mounts to /var/whatever. > > Would you fsck /var while it is mounted? No, of course not; that's why I suggest it's up to the init scripts to make sure that /proc/mounts gets propagated to /var/whatever. They usually will know enough about what's going on to take care of any special cases and add any extra info that's relevant. If a program such as `mount' wants to use mtab and finds that it's not present (possibly because /var isn't mounted), it should either use /proc/mounts instead, or just ignore it. > I think part of the problem is that /var is used for both files > we want to keep across reboot, and files we do not want to keep > across reboot. [/var/run is for `non-persistant' files] > There are cases where it is undesirable to have mtab in /var, > but if mount expect to find mtab somewhere under /var, we can't > even use a symlink to get it out of there, because /var needs > to be mounted before the symlink can be followed. It will simply appear to mount as if the file isn't present, in which case it should gracefully stop trying to use it [see above]. It seems like the attempt here is to somehow make everything just work magically _without_ modifying any tools that use mtab -- and I think that just isn't doable in every situation. -Miles -- Quidquid latine dictum sit, altum viditur. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 7:06 ` Miles Bader @ 2003-02-27 8:25 ` Kasper Dupont 2003-02-27 8:42 ` Miles Bader 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 8:25 UTC (permalink / raw) To: Miles Bader; +Cc: DervishD, Linux-kernel Miles Bader wrote: > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > /var is clearly the right place for this; > > > > Is it? > > Yes. On some systems, /var and /tmp are the _only_ read-write filesystems. OK, but then on such a system with my approach it would be possible to make /mtab.d a symlink pointing to somewhere under /var. > > > > if /var isn't mounted initially, I'd suggest that mount should > > > simply not update any file at that point, and the init-script that > > > mounts /var can be responsible from propagating information from > > > /proc/mounts to /var/whatever. > > > > Would you fsck /var while it is mounted? > > No, of course not; that's why I suggest it's up to the init scripts to > make sure that /proc/mounts gets propagated to /var/whatever. They > usually will know enough about what's going on to take care of any > special cases and add any extra info that's relevant. But AFAIK fsck uses mtab. > > If a program such as `mount' wants to use mtab and finds that it's not > present (possibly because /var isn't mounted), it should either use > /proc/mounts instead, or just ignore it. If mtab does not exist mount will attempt to create a new one with only the root listed. > > > I think part of the problem is that /var is used for both files > > we want to keep across reboot, and files we do not want to keep > > across reboot. > > [/var/run is for `non-persistant' files] But that doesn't solve the problem with ordering. If we don't want to change a lot of userspace utilities and the order in which things are done during boot, we need /var/run mounted earlier than /var. And /var/run is not the only directory with files we do not want to keep across boot. There are some in /var/lock too, and AFAIR a few other locations. > > > There are cases where it is undesirable to have mtab in /var, > > but if mount expect to find mtab somewhere under /var, we can't > > even use a symlink to get it out of there, because /var needs > > to be mounted before the symlink can be followed. > > It will simply appear to mount as if the file isn't present, in which > case it should gracefully stop trying to use it [see above]. > > It seems like the attempt here is to somehow make everything just work > magically _without_ modifying any tools that use mtab -- and I think > that just isn't doable in every situation. Maybe not, but I certainly don't want to change every program that reads mtab. If we can limit the changes to those tools that needs to write mtab, it might be feasible. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 8:25 ` Kasper Dupont @ 2003-02-27 8:42 ` Miles Bader 2003-02-27 9:21 ` jw schultz 2003-02-27 9:46 ` Kasper Dupont 0 siblings, 2 replies; 56+ messages in thread From: Miles Bader @ 2003-02-27 8:42 UTC (permalink / raw) To: Kasper Dupont; +Cc: DervishD, Linux-kernel Kasper Dupont <kasperd@daimi.au.dk> writes: > > Yes. On some systems, /var and /tmp are the _only_ read-write filesystems. > > OK, but then on such a system with my approach it would be possible to > make /mtab.d a symlink pointing to somewhere under /var. ... you could do the same with /etc/mtab. In fact since /etc is almost guaranteed to be on the same filesystem as /, it seems like "/mtab.d" offers zero advantages over just /etc/mtab -- the case where /etc/mtab is the most annoying is when /etc is R/O, but this almost always means that / will be R/O, making /mtab.d useless too. > But AFAIK fsck uses mtab. It uses /etc/fstab. > If mtab does not exist mount will attempt to create a new one with > only the root listed. Unless you use the `-n' flag, which an init-script should do if it knows there's something wierd required to get /var mounted or something. -Miles -- 80% of success is just showing up. --Woody Allen ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 8:42 ` Miles Bader @ 2003-02-27 9:21 ` jw schultz 2003-02-27 9:49 ` Miles Bader ` (2 more replies) 2003-02-27 9:46 ` Kasper Dupont 1 sibling, 3 replies; 56+ messages in thread From: jw schultz @ 2003-02-27 9:21 UTC (permalink / raw) To: Linux-kernel On Thu, Feb 27, 2003 at 05:42:30PM +0900, Miles Bader wrote: > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > Yes. On some systems, /var and /tmp are the _only_ read-write filesystems. > > > > OK, but then on such a system with my approach it would be possible to > > make /mtab.d a symlink pointing to somewhere under /var. > > ... you could do the same with /etc/mtab. > > In fact since /etc is almost guaranteed to be on the same filesystem as > /, it seems like "/mtab.d" offers zero advantages over just /etc/mtab -- > the case where /etc/mtab is the most annoying is when /etc is R/O, but > this almost always means that / will be R/O, making /mtab.d useless too. If you netboot /etc as its own filesystem make sense. Why duplicate the rest of root just for /etc. /etc, /var and /tmp are the only filesystems that have much reason to be unique to a system; all others are easily sharable and most others read-only. > > > But AFAIK fsck uses mtab. > > It uses /etc/fstab. > > > If mtab does not exist mount will attempt to create a new one with > > only the root listed. > > Unless you use the `-n' flag, which an init-script should do if it > knows there's something wierd required to get /var mounted or something. <voice of annoyance> /etc/mtab is a hack. I suspect it was done so that fsck, df and umount wouldn't have to read /dev/kmem. We now have much better ways to get data out of the kernel. The idea of storing the list of mounted filesystems on a mounted filesystem is a bad idea from the get-go. The only advantage it ever really had was the possibility to manually play mountpoint monte with mv. Duplicating the in-kernel data externally begs for inconsistencies that only get worse with pivot root. Let the data reside in the kernel and have a procfs or sysfs entity for it. A symlink from /etc/mtab can keep the old tools happy. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 9:21 ` jw schultz @ 2003-02-27 9:49 ` Miles Bader 2003-02-27 23:33 ` Kasper Dupont 2003-02-27 12:48 ` Denis Vlasenko 2003-03-02 13:04 ` DervishD 2 siblings, 1 reply; 56+ messages in thread From: Miles Bader @ 2003-02-27 9:49 UTC (permalink / raw) To: jw schultz; +Cc: Linux-kernel jw schultz <jw@pegasys.ws> writes: > /etc/mtab is a hack. I suspect it was done so that fsck, df > and umount wouldn't have to read /dev/kmem. We now have > much better ways to get data out of the kernel. Oh, I very much agree. I'm just trying to say that it's not really any worse than the _other_ stupid hacks being suggested... I think making /proc/{mount,mtab,...,whatever} work correctly is certainly the best thing to do. -Miles -- "1971 pickup truck; will trade for guns" ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 9:49 ` Miles Bader @ 2003-02-27 23:33 ` Kasper Dupont 0 siblings, 0 replies; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 23:33 UTC (permalink / raw) To: Miles Bader; +Cc: jw schultz, Linux-kernel Miles Bader wrote: > > I think making /proc/{mount,mtab,...,whatever} work correctly is > certainly the best thing to do. I think we all agree on that. But then what is the correct way for that to work? And is that possible? Should any of the fields be written by userspace utilities, or is the kernel supposed to know the right value for every field? What should be in the device field in case of loopback and bind mounts? -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 9:21 ` jw schultz 2003-02-27 9:49 ` Miles Bader @ 2003-02-27 12:48 ` Denis Vlasenko 2003-02-27 23:28 ` Kasper Dupont 2003-03-02 13:04 ` DervishD 2 siblings, 1 reply; 56+ messages in thread From: Denis Vlasenko @ 2003-02-27 12:48 UTC (permalink / raw) To: jw schultz, Linux-kernel On 27 February 2003 11:21, jw schultz wrote: > On Thu, Feb 27, 2003 at 05:42:30PM +0900, Miles Bader wrote: > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > > Yes. On some systems, /var and /tmp are the _only_ read-write > > > > filesystems. > > > > > > OK, but then on such a system with my approach it would be > > > possible to make /mtab.d a symlink pointing to somewhere under > > > /var. > > > > ... you could do the same with /etc/mtab. > > > > In fact since /etc is almost guaranteed to be on the same > > filesystem as /, it seems like "/mtab.d" offers zero advantages > > over just /etc/mtab -- the case where /etc/mtab is the most > > annoying is when /etc is R/O, but this almost always means that / > > will be R/O, making /mtab.d useless too. > > If you netboot /etc as its own filesystem make sense. Why > duplicate the rest of root just for /etc. /etc, /var and > /tmp are the only filesystems that have much reason to be > unique to a system; all others are easily sharable and most > others read-only. This is my netboot root fs, it is shared across all workstations (NB: .local is "mount --bind"ed to workstation-private directory): # ls -la / drwxr-xr-x 6 root root 4096 Mar 12 2002 .local drwxr-xr-x 15 root root 4096 Feb 14 11:12 .share dr-xr-xr-x 2 root root 4096 Jan 16 14:29 bin dr-xr-xr-x 20 root root 1024 Feb 4 13:23 boot drwxr-xr-x 1 root root 0 Jan 1 1970 dev drwxr-xr-x 3 root root 4096 Jan 16 14:29 lib dr-xr-xr-x 68 root root 0 Feb 27 15:42 proc lrwxrwxrwx 1 root root 3 Oct 24 15:20 sbin -> bin lrwxrwxrwx 1 root root 12 Nov 12 2001 root -> /.share/root lrwxrwxrwx 1 root root 12 Nov 12 2001 home -> /.share/home lrwxrwxrwx 1 root root 11 Nov 12 2001 usr -> /.share/usr lrwxrwxrwx 1 root root 11 Nov 12 2001 mnt -> /.local/mnt lrwxrwxrwx 1 root root 11 Jun 7 2002 etc -> /.local/etc lrwxrwxrwx 1 root root 11 Nov 12 2001 tmp -> /.local/tmp lrwxrwxrwx 1 root root 11 Nov 12 2001 var -> /.local/var -- vda ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 12:48 ` Denis Vlasenko @ 2003-02-27 23:28 ` Kasper Dupont 2003-02-28 6:15 ` Denis Vlasenko 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 23:28 UTC (permalink / raw) To: vda; +Cc: jw schultz, Linux-kernel Denis Vlasenko wrote: > > lrwxrwxrwx 1 root root 12 Nov 12 2001 root -> /.share/root Wouldn't it be best to keep /root on the root filesystem? It is rarely large, and if you need to log in as root to fix some mounting problem, I guess you want your home directory. > lrwxrwxrwx 1 root root 11 Nov 12 2001 mnt -> /.local/mnt What is the point in making mnt a local directory? All it contains are some directories to serve as mountpoints. I guess you are going to mount something on top of every subdirectory in mnt anyway. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 23:28 ` Kasper Dupont @ 2003-02-28 6:15 ` Denis Vlasenko 0 siblings, 0 replies; 56+ messages in thread From: Denis Vlasenko @ 2003-02-28 6:15 UTC (permalink / raw) To: Kasper Dupont; +Cc: jw schultz, Linux-kernel On 28 February 2003 01:28, Kasper Dupont wrote: > Denis Vlasenko wrote: > > lrwxrwxrwx 1 root root 12 Nov 12 2001 root -> > > /.share/root > > Wouldn't it be best to keep /root on the root filesystem? > It is rarely large, and if you need to log in as root to > fix some mounting problem, I guess you want your home > directory. No. My rootfs is RO. My home dir shouldn't be. > > lrwxrwxrwx 1 root root 11 Nov 12 2001 mnt -> > > /.local/mnt > > What is the point in making mnt a local directory? All > it contains are some directories to serve as mountpoints. > I guess you are going to mount something on top of every > subdirectory in mnt anyway. Yes. -- vda ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 9:21 ` jw schultz 2003-02-27 9:49 ` Miles Bader 2003-02-27 12:48 ` Denis Vlasenko @ 2003-03-02 13:04 ` DervishD 2003-03-02 14:16 ` Kasper Dupont 2 siblings, 1 reply; 56+ messages in thread From: DervishD @ 2003-03-02 13:04 UTC (permalink / raw) To: jw schultz, Linux-kernel Hi J.W. :) jw schultz dixit: > The idea of storing the list of mounted filesystems on a > mounted filesystem is a bad idea from the get-go. I'm with you on this, with an exception. It's a bad idea provided you have some way to know what filesystems are mounted, together with the options, etc... /bin/mount knows all those options, obviously, and the kernel not always (AFAIK). Don't know why. > Let the data reside in the kernel and have a procfs or sysfs > entity for it. A symlink from /etc/mtab can keep the old > tools happy. That's what I propose, too. Even if this lead to technical difficulties, /etc/mtab is, IMHO, obsolete and a better solution tried instead. Obviously I don't have such a solution, but I think that a procfs based solution and a symlink for mtab will work quite good. I know: some systems don't have procfs, but I think that those systems will have a read-only /etc anyway... Other solution is to link /etc/mtab to a point at /var. If 'mount' treats specially the mtab if it is a symlink... well, IMHO this is not correct. Yes, this can lead to an attack, but: 'mount' is a setuid program, and only root can symlink /etc/mtab, true? Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-02 13:04 ` DervishD @ 2003-03-02 14:16 ` Kasper Dupont 2003-03-03 1:04 ` jw schultz 2003-03-04 11:08 ` DervishD 0 siblings, 2 replies; 56+ messages in thread From: Kasper Dupont @ 2003-03-02 14:16 UTC (permalink / raw) To: DervishD; +Cc: jw schultz, Linux-kernel DervishD wrote: > > If 'mount' treats specially the > mtab if it is a symlink... well, IMHO this is not correct. Yes, this > can lead to an attack, but: 'mount' is a setuid program, and only > root can symlink /etc/mtab, true? The reason for mount not to update /etc/mtab if it is a symlink is not security concerns, but rather that it could be a symlink to /proc/mounts. Another problem is the way the update is actually done. A lockfile named /etc/mtab~ is created, and a new mtab is written to /etc/mtab.tmp which is later renamed on top of mtab. Some of this can obviously be solved by changing mount. But if we are going to change mount in non-trivial ways, we should aim for a better longterm solution. It would be possible for mount to start from /et/mtab and use readlink until the actual location is found. Then if the path starts with /proc/ the update can be skipped, or done in a different way. And if the location is outside /proc then create lockfilename and tempfilename by appending to this path. But all that is IMHO a bad solution. Getting the actual location right is nontrivial. And we should rather aim for an implementation in /proc and have mount write there directly. But there are a few open questions I'd like answered before trying to implement a /proc/mtab. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-02 14:16 ` Kasper Dupont @ 2003-03-03 1:04 ` jw schultz 2003-03-03 12:22 ` Kasper Dupont 2003-03-04 11:08 ` DervishD 1 sibling, 1 reply; 56+ messages in thread From: jw schultz @ 2003-03-03 1:04 UTC (permalink / raw) To: Linux-kernel On Sun, Mar 02, 2003 at 03:16:21PM +0100, Kasper Dupont wrote: > DervishD wrote: > > > > If 'mount' treats specially the > > mtab if it is a symlink... well, IMHO this is not correct. Yes, this > > can lead to an attack, but: 'mount' is a setuid program, and only > > root can symlink /etc/mtab, true? > > The reason for mount not to update /etc/mtab if it is a symlink is > not security concerns, but rather that it could be a symlink to > /proc/mounts. Another problem is the way the update is actually > done. A lockfile named /etc/mtab~ is created, and a new mtab is > written to /etc/mtab.tmp which is later renamed on top of mtab. > > Some of this can obviously be solved by changing mount. But if we > are going to change mount in non-trivial ways, we should aim for a > better longterm solution. It would be possible for mount to start > from /et/mtab and use readlink until the actual location is found. > Then if the path starts with /proc/ the update can be skipped, or > done in a different way. And if the location is outside /proc then > create lockfilename and tempfilename by appending to this path. > > But all that is IMHO a bad solution. Getting the actual location > right is nontrivial. And we should rather aim for an implementation > in /proc and have mount write there directly. But there are a few > open questions I'd like answered before trying to implement a > /proc/mtab. You are talking about adding hacks to workaround the original hack. Nothing should write to mtab. Say it with me "Nothing should write to mtab". mount(8) and umount(8) are the only almost the only things that write mtab all others are readers. I may be wrong but the data argument to mount(2) looks like it should support everything missing from /proc/mounts. Alternatively change mount(2) and mount(8) and any other mount(2) callers will be revealed. The reason to leave a /etc/mtab symlink is so that the old tools other than (u)mount don't need updates. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-03 1:04 ` jw schultz @ 2003-03-03 12:22 ` Kasper Dupont 2003-03-04 2:02 ` jw schultz 2003-03-04 11:16 ` DervishD 0 siblings, 2 replies; 56+ messages in thread From: Kasper Dupont @ 2003-03-03 12:22 UTC (permalink / raw) To: jw schultz; +Cc: Linux-kernel jw schultz wrote: > > On Sun, Mar 02, 2003 at 03:16:21PM +0100, Kasper Dupont wrote: > > And we should rather aim for an implementation > > in /proc and have mount write there directly. But there are a few > > open questions I'd like answered before trying to implement a > > /proc/mtab. > > You are talking about adding hacks to workaround the > original hack. Nothing should write to mtab. Say it with > me "Nothing should write to mtab". You obviously haven't read all I have written. There is nothing I'd like more than an implementation where the kernel could always provide the correct information, and mount would never have to store it anywhere else. However I don't know if that is possible, and until somebody proves it possible, we will need mtab. There are three groups of options: - VFS options - Filesystem options - Userspace options The VFS options are given to the mount system call in a bitmask, and they are available through the /proc/mounts pseudo file. The filesystem options are more complicated. They are given to mount in the data argument. When the filesystem is first mounted it would be trivial to save the string and provide it in /proc/mounts (or /proc/mtab). But if the filesystem is later remounted with a different set of options, it is nontrivial to know in general which parts should be taken from the old string, and which parts should be taken from the new strings. Even some of the filesystems have gotten this wrong and would read uninitialized variables if a remount did not specify every single possible option. Finally the userspace options are used by mount itself. One example is in the case of a user option being specified in /etc/fstab, mount will store the name of the user calling mount in /etc/mtab. I don't know if that kind of options are also given in the data argument, but they have no business in the kernel, they are only used by a feature implemented in userspace. But since they are related to a mount point, it would be nice to have the kernel delete them once the mountpoint is unmounted. As long as these options is not yet stored in the kernel, we need /etc/mtab. The question is how to get them into the kernel. One possibility would be that mount could open /proc/mtab for writing and write a single line in the usual format. Otherwise we could extent mount with another string argument, or we could put them into the data argument, where they really don't belong. Since you seem to have some opinions on how this should be done, I'd like to know how *you* would store those options. Another problem is the device field, in the most common cases /etc/mtab and /proc/mounts will contain the same. But in the case of loopback mounts and bind mounts they are different. I think the current value of the device field in /etc/mtab is somewhat broken for bind mounts, because the source could be unmounted before the target. The loopback case is not optimal either, because it works differently if you manually use losetup and if you let mount do it by specifying -o loop. Sometimes it is desirable to let mount automatically detach the loopback device even if it was not setup using -o loop, but that is not always the case. Before we can get rid of /etc/mtab we need to agree on how to solve those problems. There might be other cases I don't know about, where /etc/mtab contains special values. The remaining fields is AFAIK no problem, the current /proc/mounts implementation get them right. The target field in /proc/mounts did get fixed with 2.4, and the filesystem field also contains the right value. In the case of bind mounts /etc/mtab will contain none in the filesystem field, but I consider that to be a bug and /proc/mounts to be correct. And finally the last two fields always contain 0, and only exist to keep the format identical with /etc/fstab. > > mount(8) and umount(8) are the only almost the only things that > write mtab all others are readers. What are you saying? Are they the only writers, or are there other writers? IIRC smbmount will write /etc/mtab on its own. > I may be wrong but the > data argument to mount(2) looks like it should support > everything missing from /proc/mounts. I don't think it has everything. > Alternatively change > mount(2) and mount(8) and any other mount(2) callers will > be revealed. Sounds like a good idea on a long term. Probably it should be possible to get warnings from the kernel like it has been done with other obsolete interfaces. > > The reason to leave a /etc/mtab symlink is so that the > old tools other than (u)mount don't need updates. On a long term I agree with that. But first we need a replacement for /etc/mtab. I have come with some suggestions, but there are still a few blanks to fill in. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-03 12:22 ` Kasper Dupont @ 2003-03-04 2:02 ` jw schultz 2003-03-05 12:57 ` Kasper Dupont 2003-03-04 11:16 ` DervishD 1 sibling, 1 reply; 56+ messages in thread From: jw schultz @ 2003-03-04 2:02 UTC (permalink / raw) To: Linux-kernel On Mon, Mar 03, 2003 at 01:22:46PM +0100, Kasper Dupont wrote: > jw schultz wrote: > > > > On Sun, Mar 02, 2003 at 03:16:21PM +0100, Kasper Dupont wrote: > > > And we should rather aim for an implementation > > > in /proc and have mount write there directly. But there are a few > > > open questions I'd like answered before trying to implement a > > > /proc/mtab. > > > > You are talking about adding hacks to workaround the > > original hack. Nothing should write to mtab. Say it with > > me "Nothing should write to mtab". > > You obviously haven't read all I have written. There is nothing > I'd like more than an implementation where the kernel could > always provide the correct information, and mount would never > have to store it anywhere else. However I don't know if that is > possible, and until somebody proves it possible, we will need > mtab. I had read all you wrote in this thread. I'll grant that i might have missed what you wrote elsewhere or perhaps what you implied. > There are three groups of options: > - VFS options > - Filesystem options > - Userspace options > > The VFS options are given to the mount system call in a bitmask, > and they are available through the /proc/mounts pseudo file. > > The filesystem options are more complicated. They are given to > mount in the data argument. When the filesystem is first mounted > it would be trivial to save the string and provide it in > /proc/mounts (or /proc/mtab). But if the filesystem is later > remounted with a different set of options, it is nontrivial to > know in general which parts should be taken from the old string, > and which parts should be taken from the new strings. Even some > of the filesystems have gotten this wrong and would read > uninitialized variables if a remount did not specify every single > possible option. > > Finally the userspace options are used by mount itself. One example > is in the case of a user option being specified in /etc/fstab, > mount will store the name of the user calling mount in /etc/mtab. > I don't know if that kind of options are also given in the data > argument, but they have no business in the kernel, they are only > used by a feature implemented in userspace. But since they are > related to a mount point, it would be nice to have the kernel > delete them once the mountpoint is unmounted. OK. I was less that certain that there weren't options that couldn't be listed in data or flags. It makes sense that there would be. > As long as these options is not yet stored in the kernel, we > need /etc/mtab. The question is how to get them into the kernel. > One possibility would be that mount could open /proc/mtab for > writing and write a single line in the usual format. Otherwise > we could extent mount with another string argument, or we could > put them into the data argument, where they really don't belong. > > Since you seem to have some opinions on how this should be done, > I'd like to know how *you* would store those options. Writing to /proc/mtab like we do /etc/mtab means allowing full file read,write,truncate,seek functionality on a multi-page tlob just to emulate current behavior and support a second data source with a disconnect from the kernel. [description of problems with /etc/mtab, kernel disconnect] > Before we can get rid of /etc/mtab we need to agree on how > to solve those problems. There might be other cases I don't > know about, where /etc/mtab contains special values. > > The remaining fields is AFAIK no problem, the current > /proc/mounts implementation get them right. The target > field in /proc/mounts did get fixed with 2.4, and the > filesystem field also contains the right value. In the case > of bind mounts /etc/mtab will contain none in the filesystem > field, but I consider that to be a bug and /proc/mounts to > be correct. And finally the last two fields always contain > 0, and only exist to keep the format identical with /etc/fstab. > > > > > mount(8) and umount(8) are the only almost the only things that > > write mtab all others are readers. > > What are you saying? Are they the only writers, or are there > other writers? IIRC smbmount will write /etc/mtab on its own. Hence the qualifier. My point is that the list of things that call mount(2) directly and write to /etc/mtab is small and the most critical of them are linux specific. This gives us a degree of freedom in our approach. > > I may be wrong but the > > data argument to mount(2) looks like it should support > > everything missing from /proc/mounts. > > I don't think it has everything. OK. So it doesn't > > Alternatively change > > mount(2) and mount(8) and any other mount(2) callers will > > be revealed. > > Sounds like a good idea on a long term. Probably it should > be possible to get warnings from the kernel like it has been > done with other obsolete interfaces. > > > > > The reason to leave a /etc/mtab symlink is so that the > > old tools other than (u)mount don't need updates. > > On a long term I agree with that. But first we need a > replacement for /etc/mtab. I have come with some suggestions, > but there are still a few blanks to fill in. What i would lean towards, assuming that data couldn't list all options not supported by mountflags would be to add a char *userdata or useropts argument. That would be attached to struct vfsmount. Userdata would be what /proc/mtab or whatever reported, either as the option list or the whole line. To detect the old interface users a NULL userdata or (as alternatives) a missing MS_USERDATA flag or calling the old mount syscall would cause a warning that identifies the offending process. For the short term either construct a fake userdata or mtab could fallback to what /proc/mounts does when it hits NULL. Long term might be to fail mount(2) on such an error. I think our goals are the same. The only reason i chimed in on this discussion was to remind people that /etc/mtab was a hack we no longer really need and then because it sounded like what was being proposed was to emulate that obsolescence with another layer of cruft. Emulating the read behavior is good. A link in /etc is needed to accommodate the numerous utilities that read /etc/mtab. It is emulating the write behavior, or persisting in preserving the disconnected file, that makes me a bit uncomfortable. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-04 2:02 ` jw schultz @ 2003-03-05 12:57 ` Kasper Dupont 2003-03-06 1:18 ` jw schultz 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-03-05 12:57 UTC (permalink / raw) To: jw schultz; +Cc: Linux-kernel jw schultz wrote: > > I had read all you wrote in this thread. I'll grant that i > might have missed what you wrote elsewhere or perhaps what you > implied. Hmm, maybe it was somewhere else I wrote it then. > > Writing to /proc/mtab like we do /etc/mtab means allowing > full file read,write,truncate,seek functionality on a > multi-page tlob just to emulate current behavior and support > a second data source with a disconnect from the kernel. I certainly don't want that. I'd much rather see something slightly similar to files in /proc/sys/. I only want the write system call to work, and I don't want the write call to make use of any file offset. (Maybe it would require a buffer for cases where a write does not end with a newline, but that is just a minor detail.) Every full line written to /proc/mtab would then be parsed (as simple as finding the spaces and verify that there are exactly five). The relevant fields in the mountpoint listed in field two will then be updated. > > > > > > mount(8) and umount(8) are the only almost the only things that > > > write mtab all others are readers. > > > > What are you saying? Are they the only writers, or are there > > other writers? IIRC smbmount will write /etc/mtab on its own. > > Hence the qualifier. My point is that the list of things > that call mount(2) directly and write to /etc/mtab is small > and the most critical of them are linux specific. This > gives us a degree of freedom in our approach. We agree on that. > > What i would lean towards, assuming that data couldn't list > all options not supported by mountflags would be to add a > char *userdata or useropts argument. That would be attached > to struct vfsmount. Userdata would be what /proc/mtab or > whatever reported, either as the option list or the whole > line. > > To detect the old interface users a NULL userdata or (as > alternatives) a missing MS_USERDATA flag or calling the old > mount syscall would cause a warning that identifies the > offending process. For the short term either construct a > fake userdata or mtab could fallback to what /proc/mounts > does when it hits NULL. Long term might be to fail mount(2) > on such an error. That is another possible solution. And as I think a litle more about it, that is probably a better than the solution I suggested. There are a few details of the API that needs to be defined before it can be implemented. So I hope people will say how they like it. As I see it there are a few different possibilities: 1) Make a new mount system call. Finally get rid of the old magic value in the flag register and add the extra argument which is then required. Make the old mount system call obsolete, but keep it for some versions. The old mount system call should then just behave as if the user data was the empty string. 2) Add a new flag for the old mount system call, which indicates that there is one more argument containing the user data. > > I think our goals are the same. Yes. > The only reason i chimed in > on this discussion was to remind people that /etc/mtab was a > hack we no longer really need and then because it sounded > like what was being proposed was to emulate that > obsolescence with another layer of cruft. I never wanted a /proc/mtab to emulate the existing /etc/mtab. In fact I wanted it to resemble the existing /proc/mounts as much as possible, just with a few new features and probably a different string in the device field in some cases. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-05 12:57 ` Kasper Dupont @ 2003-03-06 1:18 ` jw schultz 2003-03-06 23:30 ` Kasper Dupont 0 siblings, 1 reply; 56+ messages in thread From: jw schultz @ 2003-03-06 1:18 UTC (permalink / raw) To: Linux-kernel On Wed, Mar 05, 2003 at 01:57:57PM +0100, Kasper Dupont wrote: > jw schultz wrote: > > Writing to /proc/mtab like we do /etc/mtab means allowing > > full file read,write,truncate,seek functionality on a > > multi-page tlob just to emulate current behavior and support > > a second data source with a disconnect from the kernel. > > I certainly don't want that. I'd much rather see something > slightly similar to files in /proc/sys/. I only want the > write system call to work, and I don't want the write call > to make use of any file offset. (Maybe it would require a > buffer for cases where a write does not end with a newline, > but that is just a minor detail.) Every full line written > to /proc/mtab would then be parsed (as simple as finding > the spaces and verify that there are exactly five). The > relevant fields in the mountpoint listed in field two will > then be updated. And umount? Anything that umounts or remountes a filesystem has to modify /etc/mtab to remove or alter the relevant line. I traced a umount and it did the write-to-temp+rename routine. I wouldn't expect that to work to well in proc. And you should have seen the ugly fstat64,_llseek,write loop it used. To put this in kernel means changing how it is updated. Once we do that we might as well go all the way. > > What i would lean towards, assuming that data couldn't list > > all options not supported by mountflags would be to add a > > char *userdata or useropts argument. That would be attached > > to struct vfsmount. Userdata would be what /proc/mtab or > > whatever reported, either as the option list or the whole > > line. > > > > To detect the old interface users a NULL userdata or (as > > alternatives) a missing MS_USERDATA flag or calling the old > > mount syscall would cause a warning that identifies the > > offending process. For the short term either construct a > > fake userdata or mtab could fallback to what /proc/mounts > > does when it hits NULL. Long term might be to fail mount(2) > > on such an error. > > That is another possible solution. And as I think a litle > more about it, that is probably a better than the solution I > suggested. > > There are a few details of the API that needs to be defined > before it can be implemented. So I hope people will say how > they like it. As I see it there are a few different > possibilities: > > 1) Make a new mount system call. Finally get rid of the old > magic value in the flag register and add the extra argument > which is then required. Make the old mount system call > obsolete, but keep it for some versions. The old mount > system call should then just behave as if the user data > was the empty string. > > 2) Add a new flag for the old mount system call, which > indicates that there is one more argument containing the > user data. #2 with warnings i like better than keeping a deprecated mount syscall until 2038. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-06 1:18 ` jw schultz @ 2003-03-06 23:30 ` Kasper Dupont 0 siblings, 0 replies; 56+ messages in thread From: Kasper Dupont @ 2003-03-06 23:30 UTC (permalink / raw) To: jw schultz, Linux-Kernel jw schultz wrote: > > And umount? Anything that umounts or remountes a filesystem > has to modify /etc/mtab to remove or alter the relevant > line. That is not an issue. With my suggestion the line is automatically removed by the kernel at umount. If the umount program changes the line before calling the umount system call, the changed line is discareded anyway. If the umount program try to change the line after calling umount, it is simply ignored. Currently this is not going to happen anyway with a umount program that see /etc/mtab is a symlink and simply skips the update. An updated umount program for the new approach will simply remove all the code related to updating mtab. > > To put this in kernel means changing how it is updated. > Once we do that we might as well go all the way. Yes, in this case it means umount is not going to write at all. It only needs to read the file for the user specific options. (To know if the calling user is allowed to umount.) The read can be done either through the /etc/mtab symlink or the /proc interface, I prefer the later. > > > > 1) Make a new mount system call. Finally get rid of the old > > magic value in the flag register and add the extra argument > > which is then required. Make the old mount system call > > obsolete, but keep it for some versions. The old mount > > system call should then just behave as if the user data > > was the empty string. > > > > 2) Add a new flag for the old mount system call, which > > indicates that there is one more argument containing the > > user data. > > #2 with warnings i like better than keeping a deprecated mount > syscall until 2038. But by adding options to the existing systemcall we are going to keep historic options and magic values in that system call forever. With the new system call we have at least collected all the historic parts in a single obsolete system call, that can eventually be removed. Anyway I think this is a minor detail, both approaches will be an improvement over the current mtab file. So whatever people prefer I'd be happy with. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-03 12:22 ` Kasper Dupont 2003-03-04 2:02 ` jw schultz @ 2003-03-04 11:16 ` DervishD 1 sibling, 0 replies; 56+ messages in thread From: DervishD @ 2003-03-04 11:16 UTC (permalink / raw) To: Kasper Dupont; +Cc: jw schultz, Linux-kernel Hi Kasper and J.W. :) Kasper Dupont dixit: > As long as these options is not yet stored in the kernel, we > need /etc/mtab. The question is how to get them into the kernel. That was my first question. Certainly there should be a way to tell the kernel those options, but... Do we really need them. As you said, those options (the user options) are used by mount itself, so the kernel doesn't need to know them. If we are concerned by the 'user' option, that allows normal users to mount and umount filesystems, and that option is not in the syscall, I think that it should be done with other approach. See below. > Before we can get rid of /etc/mtab we need to agree on how > to solve those problems. There might be other cases I don't > know about, where /etc/mtab contains special values. In the case of normal users mounting and umounting filesystems, this could be done throught the use of capabilities, I think. And surely better methods exist. If we could tell the kernel that some user 'a' mounted filesystem 'f', then at umount time the umount syscall will only success if root or 'a' umounts 'f'. The question is if we can tell it to the kernel. The mount syscall maybe? Maybe a VFS flag just for this purpose (that seems to be very important). Other user flats like the permissions, etc... are merely informative and that info is present in /etc/fstab anyway (usually). The loopback issue is more a problem of consistency, I think. Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-02 14:16 ` Kasper Dupont 2003-03-03 1:04 ` jw schultz @ 2003-03-04 11:08 ` DervishD 1 sibling, 0 replies; 56+ messages in thread From: DervishD @ 2003-03-04 11:08 UTC (permalink / raw) To: Kasper Dupont; +Cc: jw schultz, Linux-kernel Hi Kasper :) Kasper Dupont dixit: > > If 'mount' treats specially the > > mtab if it is a symlink... well, IMHO this is not correct. Yes, this > The reason for mount not to update /etc/mtab if it is a symlink is > not security concerns, but rather that it could be a symlink to > /proc/mounts. Another problem is the way the update is actually > done. A lockfile named /etc/mtab~ is created, and a new mtab is > written to /etc/mtab.tmp which is later renamed on top of mtab. The lockfile was the first reason why we did the symlink. The /etc was readonly and mount failed. > But if we > are going to change mount in non-trivial ways, we should aim for a > better longterm solution. You're completely right ;) But, just as I told before, I have no good solution. I don't remember clearly, but I think that we use finally another solution for the embedded system, by using a 'fake' etc, writeable, and after booting, mounting a readonly etc over the old one, or something like that. Pretty good (I suppose) for the embedded system, but not a solution for everyday use, IMHO. By now I will do with /etc/mtab, but I think I will replace it with a symlink to /proc, no matter if I lose options, etc... And really I would like to write my own mount, just for my system, as I've already done with other binaries. That's what I like free software: I can write my own software without doing all the work from zero, using the brains of people far more clever than me for helping in the effort ;)) BTW, thanks for your interest in the issue :)) Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 8:42 ` Miles Bader 2003-02-27 9:21 ` jw schultz @ 2003-02-27 9:46 ` Kasper Dupont 2003-02-27 9:58 ` Miles Bader 1 sibling, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 9:46 UTC (permalink / raw) To: Miles Bader; +Cc: DervishD, Linux-kernel Miles Bader wrote: > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > Yes. On some systems, /var and /tmp are the _only_ read-write filesystems. > > > > OK, but then on such a system with my approach it would be possible to > > make /mtab.d a symlink pointing to somewhere under /var. > > ... you could do the same with /etc/mtab. No. 1) mtab being a symlink is interpreted differently by mount. You need to symlink the directory containing mtab, not mtab itself. 2) Some people might want /etc to be mounted from a different filesystem. My first change was to use /etc/mtab.d/mtab, and that works fine as long as /etc is on the root filesystem. > > In fact since /etc is almost guaranteed to be on the same filesystem as > /, it seems like "/mtab.d" offers zero advantages over just /etc/mtab -- > the case where /etc/mtab is the most annoying is when /etc is R/O, but > this almost always means that / will be R/O, making /mtab.d useless too. If /etc is in fact on the root, then /etc/mtab.d/mtab will work as well as /mtab.d/mtab. But /etc/mtab does have a disadvantage because I cannot symlink it to a different location. All I want is the possibility to place a symlink pointing to the most desired location for the particular system. So the symlink itself must be guaranteed to be on the root. Is there any directory beyond / which we can be sure is on the root filesystem? Introducing problems just because you don't want to look at the entry in the root seems like a bad idea to me. I think we need a location that is guaranteed to be on the root filesystem, which could be the root itself, if it needs to. But perhaps we should then say that we require /etc to be on the root filesystem. Since people are going to need a lot of hacks anyway if they want their /etc elsewhere. In that case I just propose we move mtab into a subdirectory, because then that subdirectory can be replaced by a symlink if anybody desires to. And the symlink itself can be considered a configuration option specifying the location of mtab, and as such does belong in /etc. > > > But AFAIK fsck uses mtab. > > It uses /etc/fstab. [kasperd:pts/0:~] grep /etc/mtab /sbin/fsck* Binary file /sbin/fsck.ext2 matches Binary file /sbin/fsck.ext3 matches Binary file /sbin/fsck.minix matches [kasperd:pts/0:~] > > > If mtab does not exist mount will attempt to create a new one with > > only the root listed. > > Unless you use the `-n' flag, which an init-script should do if it > knows there's something wierd required to get /var mounted or something. Of course the -n flag can be used to some extent, but that doesn't solve all our problems. Current rc.sysinit implementations does use -n to mount a few filesystems, and later uses -f to initialize the mtab. But all that happens before running fsck, so if /var is mounted that early, we are going to fsck it mounted. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 9:46 ` Kasper Dupont @ 2003-02-27 9:58 ` Miles Bader 2003-02-27 12:26 ` Gabriel Paubert 0 siblings, 1 reply; 56+ messages in thread From: Miles Bader @ 2003-02-27 9:58 UTC (permalink / raw) To: Kasper Dupont; +Cc: DervishD, Linux-kernel Kasper Dupont <kasperd@daimi.au.dk> writes: > > > But AFAIK fsck uses mtab. > > > > It uses /etc/fstab. > > [kasperd:pts/0:~] grep /etc/mtab /sbin/fsck* > Binary file /sbin/fsck.ext2 matches > Binary file /sbin/fsck.ext3 matches > Binary file /sbin/fsck.minix matches > [kasperd:pts/0:~] God know why; the versions (e2fsprogs 1.32) on my system don't, so it's probably not something very important. fsck should still work fine. > > Unless you use the `-n' flag, which an init-script should do if it > > knows there's something wierd required to get /var mounted or something. > > Of course the -n flag can be used to some extent, but that doesn't > solve all our problems. Current rc.sysinit implementations does use > -n to mount a few filesystems, and later uses -f to initialize the > mtab. But all that happens before running fsck, so if /var is mounted > that early, we are going to fsck it mounted. So the init scripts are badly written, what can I say? `Don't do that.' -Miles -- "Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join." -- Anon. British Officer in WW I ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 9:58 ` Miles Bader @ 2003-02-27 12:26 ` Gabriel Paubert 0 siblings, 0 replies; 56+ messages in thread From: Gabriel Paubert @ 2003-02-27 12:26 UTC (permalink / raw) To: Miles Bader; +Cc: Kasper Dupont, DervishD, Linux-kernel On Thu, Feb 27, 2003 at 06:58:59PM +0900, Miles Bader wrote: > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > > But AFAIK fsck uses mtab. > > > > > > It uses /etc/fstab. > > > > [kasperd:pts/0:~] grep /etc/mtab /sbin/fsck* > > Binary file /sbin/fsck.ext2 matches > > Binary file /sbin/fsck.ext3 matches > > Binary file /sbin/fsck.minix matches > > [kasperd:pts/0:~] > > God know why; the versions (e2fsprogs 1.32) on my system don't, so it's > probably not something very important. fsck should still work fine. Do you have a statically or dynamically linked e2fsck? On my system /etc/mtab is not in /sbin/e2fsck but it is in /lib/libext2fs.so.2 and also in the statically linked version of e2fsck. Gabriel ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 6:40 ` Kasper Dupont 2003-02-27 7:03 ` Joseph Wenninger 2003-02-27 7:06 ` Miles Bader @ 2003-02-27 7:07 ` Joseph Wenninger 2003-02-27 7:08 ` Dominik Kubla 3 siblings, 0 replies; 56+ messages in thread From: Joseph Wenninger @ 2003-02-27 7:07 UTC (permalink / raw) To: linux-kernel Hi Am Don, 2003-02-27 um 07.40 schrieb Kasper Dupont: > Miles Bader wrote: > > > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > I don't think you can put all the information from /etc/mtab > > > into /proc/mounts without breaking compatibility. > > For KDE 3.1 I've written a mount watcher, which checks the modification time of the /etc/mtab to recognize mount/unmount activity, which broke for linux from scratch( for now, they have updated there install instructions), because they linked to /proc/mounts, which doesn't seem to support mtime. If the mtab is really completly removed, is there something else I can use to track mount activities from userspace ? I don't want to retrieve the whole mounted list all the time and compare each entry to my internally stored list, just to find out that nothing has changed anyways. Kind regards Joseph Wenninger ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 6:40 ` Kasper Dupont ` (2 preceding siblings ...) 2003-02-27 7:07 ` Joseph Wenninger @ 2003-02-27 7:08 ` Dominik Kubla 2003-02-27 8:12 ` Kasper Dupont 3 siblings, 1 reply; 56+ messages in thread From: Dominik Kubla @ 2003-02-27 7:08 UTC (permalink / raw) To: Kasper Dupont, Miles Bader; +Cc: DervishD, Linux-kernel On Thursday 27 February 2003 07:40, Kasper Dupont wrote: > Miles Bader wrote: > > Kasper Dupont <kasperd@daimi.au.dk> writes: > > > My suggestion would be to change it from /etc/mtab to /mtab.d/mtab. > > > > Please, no. don't pollute the root (_especially_ with little one-use > > directories like that). > > Unfortunately it is the best solution I can come up with. > > > /var is clearly the right place for this; > > Is it? I would recommend to replace /etc/mtab with a pseudo-FS like Sun did for /etc/mnttab: # uname -rs SunOS 5.8 # mount -p ... mnttab - /etc/mnttab mntfs - no dev=39c0000 ... Regards, Dominik -- "What this country needs is a short, victorious war to stem the tide of revolution." (V.K. von Plehve, Russian Minister of Interior on the eve of the Russo-Japanese war.) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 7:08 ` Dominik Kubla @ 2003-02-27 8:12 ` Kasper Dupont 2003-02-27 9:11 ` Dominik Kubla 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 8:12 UTC (permalink / raw) To: Dominik Kubla; +Cc: Miles Bader, DervishD, Linux-kernel Dominik Kubla wrote: > > I would recommend to replace /etc/mtab with a pseudo-FS like Sun did > for /etc/mnttab: > > # uname -rs > SunOS 5.8 > # mount -p > ... > mnttab - /etc/mnttab mntfs - no dev=39c0000 > ... How does that thing behave? I have considered a /proc/mtab implementation, that might be slightly similar. It would have to be like /proc/mounts, but differ in a few fields. The mountpoint and filesystem fields should be exactly like /proc/mounts, while the device and options fields should be strings initialized with the same values as /proc/mounts, but otherwise writable from userspace. Every line written to /proc/mtab should be parsed into the fields, and the mountpoints should be searched for a match, if a match is found, the device and options fields are updated, otherwise the write is simply ignored. How does people like this idea? Should something more be done about the options field? Should they be checked for obvious inconsistencies, or should a write attempt to remount the filesystem with the new options? -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 8:12 ` Kasper Dupont @ 2003-02-27 9:11 ` Dominik Kubla 2003-02-27 16:00 ` Horst von Brand 0 siblings, 1 reply; 56+ messages in thread From: Dominik Kubla @ 2003-02-27 9:11 UTC (permalink / raw) To: Kasper Dupont; +Cc: Miles Bader, DervishD, Linux-kernel On Thursday 27 February 2003 09:12, Kasper Dupont wrote: > Dominik Kubla wrote: > > I would recommend to replace /etc/mtab with a pseudo-FS like Sun did > > for /etc/mnttab: ... > How does that thing behave? I have considered a /proc/mtab implementation, > that might be slightly similar. Quoting the Solaris 8 man page: File Formats mnttab(4) NAME mnttab - mounted file system table DESCRIPTION The file /etc/mnttab is really a file system that provides read-only access to the table of mounted file systems for the current host. /etc/mnttab is read by programs using the routines described in getmntent(3C). Mounting a file system adds an entry to this table. Unmounting removes an entry from this table. Remounting a file system causes the infor- mation in the mounted file system table to be updated to reflect any changes caused by the remount. The list is main- tained by the kernel in order of mount time. That is, the first mounted file system is first in the list and the most recently mounted file system is last. When mounted on a mount point the file system appears as a regular file con- taining the current mnttab information. [...] NOTES The snapshot of the mnttab information is taken any time a read(2) is performed at offset 0 (the beginning) of the mnttab file. The file modification time returned by stat(2) for the mnttab file is the time of the last change to mounted file system information. A poll(2) system call requesting a POLLRDBAND event can be used to block and wait for the system's mounted file system information to be dif- ferent from the most recent snapshot since the mnttab file was opened. Regards, Dominik Kubla -- "What this country needs is a short, victorious war to stem the tide of revolution." (V.K. von Plehve, Russian Minister of Interior on the eve of the Russo-Japanese war.) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 9:11 ` Dominik Kubla @ 2003-02-27 16:00 ` Horst von Brand 2003-02-27 16:31 ` Christoph Hellwig 2003-02-27 16:40 ` Dominik Kubla 0 siblings, 2 replies; 56+ messages in thread From: Horst von Brand @ 2003-02-27 16:00 UTC (permalink / raw) To: Dominik Kubla; +Cc: Kasper Dupont, Miles Bader, DervishD, Linux-kernel Dominik Kubla <dominik@kubla.de> said: > On Thursday 27 February 2003 09:12, Kasper Dupont wrote: > > Dominik Kubla wrote: > > > I would recommend to replace /etc/mtab with a pseudo-FS like Sun did > > > for /etc/mnttab: > ... > > How does that thing behave? I have considered a /proc/mtab implementation, > > that might be slightly similar. > > Quoting the Solaris 8 man page: I fail to see any significant difference to /proc/mounts (possibly expanded). Sure, /proc is the wrong place for this kind of stuff, but... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 16:00 ` Horst von Brand @ 2003-02-27 16:31 ` Christoph Hellwig 2003-02-27 16:40 ` Dominik Kubla 1 sibling, 0 replies; 56+ messages in thread From: Christoph Hellwig @ 2003-02-27 16:31 UTC (permalink / raw) To: Horst von Brand Cc: Dominik Kubla, Kasper Dupont, Miles Bader, DervishD, Linux-kernel On Thu, Feb 27, 2003 at 01:00:12PM -0300, Horst von Brand wrote: > I fail to see any significant difference to /proc/mounts (possibly expanded). > Sure, /proc is the wrong place for this kind of stuff, but... In this rare case it's not. /proc/mounts in fact is only a link to /proc/self/mounts and that is needed because wecan have per-process private namespace in Linux now. (of course this drives the traditional /etc/mtab completly useless) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 16:00 ` Horst von Brand 2003-02-27 16:31 ` Christoph Hellwig @ 2003-02-27 16:40 ` Dominik Kubla 2003-02-27 19:47 ` Kasper Dupont 1 sibling, 1 reply; 56+ messages in thread From: Dominik Kubla @ 2003-02-27 16:40 UTC (permalink / raw) To: Horst von Brand; +Cc: Kasper Dupont, Miles Bader, DervishD, Linux-kernel On Thursday 27 February 2003 17:00, Horst von Brand wrote: > Dominik Kubla <dominik@kubla.de> said: > > Quoting the Solaris 8 man page: > > I fail to see any significant difference to /proc/mounts (possibly > expanded). Sure, /proc is the wrong place for this kind of stuff, but... Then i suggest that you re-read the mnttab(4) man page and compare it to the Linux implementation. :-) Keep in mind that i only qouted some parts of the man page. Some thing are just details (but as we all know details do matter): [Linux] # ls -l /proc mounts lrwxrwxrwx 1 root root 11 Feb 27 17:10 /proc/mounts -> self/mounts # ls -l /proc/self/mounts -r--r--r-- 1 root root 0 Feb 27 17:11 /proc/self/mounts # wc -c /proc/self/mounts 1058 /proc/self/mounts [Solaris] # ls -l /etc/mnttab r--r--r-- 1 root 1178 Feb 25 16:26 /etc/mnttab # wc -c /etc/mnttab 1178 /etc/mnttab The snapshot feature as quoted in the man page is not present under Linux. The poll(2) feature is not implemented. The solaris mntfs also implements special ioctrls. Quoting the man page again: [...] IOCTLS The following ioctl(2) calls are supported: MNTIOC_NMOUNTS Returns the count of mounted resources in the current snapshot in the uint32_t pointed to by arg. MNTIOC_GETDEVLIST Returns an array of uint32_t's that is twice as long as the length returned by MNTIOC_NMOUNTS. Each pair of numbers is the major and minor device number for the file system at the corresponding line in the current /etc/mnttab snapshot. arg points to the memory buffer to receive the device number information. MNTIOC_SETTAG Sets a tag word into the options list for a mounted file system. A tag is a notation that will appear in the options string of a mounted file system but it is not recognized or interpreted by the file system code. arg points to a filled in mnttagdesc structure, as shown in the following example: uint_t mtd_major; /* major number for mounted fs */ uint_t mtd_minor; /* minor number for mounted fs */ char *mtd_mntpt; /* mount point of file system */ char *mtd_tag; /* tag to set/clear */ If the tag already exists then it is marked as set but not re-added. Tags can be at most MAX_MNTOPT_TAG long. MNTIOC_CLRTAG Marks a tag in the options list for a mounted file system as not set. arg points to the same structure as MNTIOC_SETTAG, which identifies the file system and tag to be cleared. [...] There is also an extended set of library functions to go along with that, eg. getmntany(3), getextmntent(3), resetmnttab(3) and hasmntopt(3). It is very helpful that one can get the time a mount happened! You can not get this kind of information on Linux, neither from /etc/mtab nor from /proc/self/mounts. getextmnttab(3) also gives easy access to the device major and minor number of the mount point. So there are quite some differences between the Linux proc file and the Solaris mntfs filesystem. If these differences justify us doing it the same way is debateable. The strongest argument i see is: It's already been done this way by one major Unix version, so why should Linux reinvent the wheel. Again. Regards, Dominik -- "What this country needs is a short, victorious war to stem the tide of revolution." (V.K. von Plehve, Russian Minister of Interior on the eve of the Russo-Japanese war.) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 16:40 ` Dominik Kubla @ 2003-02-27 19:47 ` Kasper Dupont 2003-02-27 22:13 ` Valdis.Kletnieks 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 19:47 UTC (permalink / raw) To: Dominik Kubla; +Cc: Horst von Brand, Miles Bader, DervishD, Linux-kernel Dominik Kubla wrote: > > So there are quite some differences between the Linux proc file and > the Solaris mntfs filesystem. If these differences justify us doing it the > same way is debateable. > > The strongest argument i see is: It's already been done this way by one > major Unix version, so why should Linux reinvent the wheel. Again. The reason for implementing that would IMHO not be to just get the features that solaris has, but rather to get rid of /etc/mtab. I guess we all agree, that a kernel implementation, that being a misc char device or a proc pseudo file would be better than the current /etc/mtab file. But I think a kernel implementation is also the most tricky. Bind mounting /proc/mounts onto /etc/mtab would to some extent resemble the solaris implementation, but there are noticable differences. I think one major question is if we can actually make a kernel implementation that without help from userspace will provide all the information that we have usually gotten from /etc/mtab. If that is possible, I think we should aim for that and thereby make /etc/mtab obsolete. Then we can eventually replace /etc/mtab with a symlink pointing to /proc/mtab, /proc/self/mtab, or /proc/1/mtab. The fact that solaris makes a snapshot of the mountpoints might be convenient, but really not that important. The correct size reported by stat is also just a convenience. The exact reporting of mtime is as already pointed out of real value to some applications. And the ioctl to get major and minor is certainly helpful if the device field is reused for other purposes in the case of bind mounts and loopback mounts. Does solaris actually have those features, and what does mnttab report in those cases? And while we are discussing bind mounts, there is one feature that I have sometimes missed: A possibility to directly mount a subdirectory of a filesystem without having to mount the root of that filesystem first and use a bindmount afterwards. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 19:47 ` Kasper Dupont @ 2003-02-27 22:13 ` Valdis.Kletnieks 2003-02-27 22:31 ` Kasper Dupont 0 siblings, 1 reply; 56+ messages in thread From: Valdis.Kletnieks @ 2003-02-27 22:13 UTC (permalink / raw) To: Kasper Dupont; +Cc: Linux-kernel [-- Attachment #1: Type: text/plain, Size: 1180 bytes --] On Thu, 27 Feb 2003 20:47:05 +0100, Kasper Dupont said: > mnttab report in those cases? And while we are discussing bind mounts, there > is one feature that I have sometimes missed: A possibility to directly mount > a subdirectory of a filesystem without having to mount the root of that > filesystem first and use a bindmount afterwards. Hmm.. so what you mean is being able to have a filesystem called (for example) /somewhere, and being able to mount /somewhere/deep/path/like/this on a mountpoint /wherever/else, but without having /somewhere mounted itself? That looks *almost* doable, except that things like quotas or the free block list would be a hassle if then you also went and mounted /somewhere/deep/other/path on /something/else Or did you want to do 'mount /somewhere/deep /wherever/else' when it's /wherever that isn't actually mounted? This looks more.. umm.. interesting, as you could (for instance) use an automounter to mount /home/fred, /home/george /home/sally, and not actually need a /home? But don't current automounters almost do this already? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 22:13 ` Valdis.Kletnieks @ 2003-02-27 22:31 ` Kasper Dupont 2003-02-27 23:54 ` Miquel van Smoorenburg 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-02-27 22:31 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Linux-kernel Valdis.Kletnieks@vt.edu wrote: > > On Thu, 27 Feb 2003 20:47:05 +0100, Kasper Dupont said: > > > mnttab report in those cases? And while we are discussing bind mounts, there > > is one feature that I have sometimes missed: A possibility to directly mount > > a subdirectory of a filesystem without having to mount the root of that > > filesystem first and use a bindmount afterwards. > > Hmm.. so what you mean is being able to have a filesystem called (for example) > /somewhere, and being able to mount /somewhere/deep/path/like/this on a > mountpoint /wherever/else, but without having /somewhere mounted itself? Yes. > That looks *almost* doable, except that things like quotas or the free > block list would be a hassle if then you also went and mounted > /somewhere/deep/other/path on /something/else It is doable. And you don't need to change the filesystems themselves. In fact VFS has most of the support right now. It can be done in userspace, I can do it by first mounting /somewhere then use --bind and finally unomount /somewhere. The reason I brought it up is that if we are going to change mount, we might want to add this feature, and we should find some better strings for the device field in mtab. Right now the sequence of commands I suggested would leave the name of an unmounted filesystem in a device field in the mtab file. Perhaps rather than writing the oldparth, it would be wiser to write device:path in the device field, where path would be path relative to the root of the filesystem. Then that same notation could be supported by mount, and implemented by temporarily mounting the root of that filesystem. The only case that couldn't be done from userspace is mounting of the root. Now some people might say nobody would need that feature, and it could be done using initrd and some pivot_root stuff anyway. But in fact a very similar feature already exists in the umsdos filesystem. IMHO that feature should be removed from umsdos and reimplemented using pivot_root instead. Then at the same time the hardcoded paths could be changable through boot options, and the feature could become filesystem independend. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 22:31 ` Kasper Dupont @ 2003-02-27 23:54 ` Miquel van Smoorenburg 2003-02-28 1:37 ` Miles Bader 0 siblings, 1 reply; 56+ messages in thread From: Miquel van Smoorenburg @ 2003-02-27 23:54 UTC (permalink / raw) To: linux-kernel In article <3E5E91B2.8EACF7D0@daimi.au.dk>, Kasper Dupont <kasperd@daimi.au.dk> wrote: >The only case that couldn't be done from userspace is mounting of the >root. Now some people might say nobody would need that feature, and it >could be done using initrd and some pivot_root stuff anyway. Well, the kernel already has a simple rootfs built-in, on top of which the real root filesystem gets mounted at boot-time. Also POSIX makes a difference between '/' and '//'. '//' might point to a different namespace. So why not mount rootfs on '//', mount the real rootfilesystem on //root, then chroot to //root (while keeping it possible to chdir("//") ). If mkdir and rmdir is added to rootfs, you could even mount //mtab.d there, or //proc, or //devfs, whatever you want to have available when the root filesystem is being fscked or not even mounted yet. Perhaps the kernel should mount all those pseudofilesystems there by default even. Apollo/DomainOS had this '//' thing, used for something different (it was the equivalent of their /net autofs mountpoint) but it worked quite well and didn't get in the way of normal '/' operation. Mike. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job -- Douglas Adams. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 23:54 ` Miquel van Smoorenburg @ 2003-02-28 1:37 ` Miles Bader 0 siblings, 0 replies; 56+ messages in thread From: Miles Bader @ 2003-02-28 1:37 UTC (permalink / raw) To: Miquel van Smoorenburg; +Cc: linux-kernel miquels@cistron-office.nl (Miquel van Smoorenburg) writes: > So why not mount rootfs on '//', mount the real rootfilesystem > on //root, then chroot to //root (while keeping it possible to > chdir("//") ). Because it's _extremely_ common for `//...' to be generated by tools constructing pathnames, when what's really meant is `/...' (which is fine, because normally it makes no difference). > Apollo/DomainOS had this '//' thing, used for something different > (it was the equivalent of their /net autofs mountpoint) but it > worked quite well and didn't get in the way of normal '/' operation. Really? I'm skeptical... -Miles -- I'd rather be consing. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-27 4:14 ` Miles Bader 2003-02-27 6:40 ` Kasper Dupont @ 2003-03-02 12:53 ` DervishD 2003-03-02 14:00 ` Kasper Dupont 1 sibling, 1 reply; 56+ messages in thread From: DervishD @ 2003-03-02 12:53 UTC (permalink / raw) To: Miles Bader; +Cc: Kasper Dupont, Linux-kernel Hi Miles :) Miles Bader dixit: > /var is clearly the right place for this; if /var isn't mounted > initially, I'd suggest that mount should simply not update any file > at that point, and the init-script that mounts /var can be > responsible from propagating information from /proc/mounts to > /var/whatever. In an embedded system I built a time ago, /etc/mtab was first a symlink to /proc/mounts, but after a while I made it a symlink to /var/run/mtab. It worked OK, AFAIK. Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-02 12:53 ` DervishD @ 2003-03-02 14:00 ` Kasper Dupont 2003-03-04 11:02 ` DervishD 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-03-02 14:00 UTC (permalink / raw) To: DervishD; +Cc: Miles Bader, Linux-kernel DervishD wrote: > > Hi Miles :) > > Miles Bader dixit: > > /var is clearly the right place for this; if /var isn't mounted > > initially, I'd suggest that mount should simply not update any file > > at that point, and the init-script that mounts /var can be > > responsible from propagating information from /proc/mounts to > > /var/whatever. > > In an embedded system I built a time ago, /etc/mtab was first a > symlink to /proc/mounts, but after a while I made it a symlink to > /var/run/mtab. It worked OK, AFAIK. Did mount actually update the mtab file? The version of mount on my system would not. -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-02 14:00 ` Kasper Dupont @ 2003-03-04 11:02 ` DervishD 2003-03-04 12:09 ` Kasper Dupont 0 siblings, 1 reply; 56+ messages in thread From: DervishD @ 2003-03-04 11:02 UTC (permalink / raw) To: Kasper Dupont; +Cc: Miles Bader, Linux-kernel Hi Kasper :) Kasper Dupont dixit: > > Miles Bader dixit: > > > /var is clearly the right place for this; if /var isn't mounted > > > initially, I'd suggest that mount should simply not update any file > > > at that point, and the init-script that mounts /var can be > > > responsible from propagating information from /proc/mounts to > > > /var/whatever. > > In an embedded system I built a time ago, /etc/mtab was first a > > symlink to /proc/mounts, but after a while I made it a symlink to > > /var/run/mtab. It worked OK, AFAIK. > Did mount actually update the mtab file? The version of mount on > my system would not. Of course not, it is just a symlink to a proc file ;))) I must say that it worked OK but really only ext2 filesystems and a CDROM were mounted, with default options. Don't know if the symlink would have been worked if special options were used. Now that I remember, we only use 'special' options for the CDROM (to allow mounting by normal users) and the devpts (the permissions). Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-04 11:02 ` DervishD @ 2003-03-04 12:09 ` Kasper Dupont 2003-03-04 14:53 ` DervishD 0 siblings, 1 reply; 56+ messages in thread From: Kasper Dupont @ 2003-03-04 12:09 UTC (permalink / raw) To: DervishD; +Cc: Miles Bader, Linux-kernel DervishD wrote: > > Hi Kasper :) > > Kasper Dupont dixit: > > > but after a while I made it a symlink to > > > /var/run/mtab. It worked OK, AFAIK. > > Did mount actually update the mtab file? The version of mount on > > my system would not. > > Of course not, it is just a symlink to a proc file But you just said it was a symlink to /var/run/mtab. Did /var/run/mtab get updated? -- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-03-04 12:09 ` Kasper Dupont @ 2003-03-04 14:53 ` DervishD 0 siblings, 0 replies; 56+ messages in thread From: DervishD @ 2003-03-04 14:53 UTC (permalink / raw) To: Kasper Dupont; +Cc: Miles Bader, Linux-kernel Hi Kasper :) Kasper Dupont dixit: > > > > but after a while I made it a symlink to > > > > /var/run/mtab. It worked OK, AFAIK. > > > Did mount actually update the mtab file? The version of mount on > > > my system would not. > > Of course not, it is just a symlink to a proc file > But you just said it was a symlink to /var/run/mtab. Excuse me, I thought that you was talking about the /proc/mounts symlink, and not /var/run/mtab. When the symlink was /var/run/mtab I don't remeber if it was updated, but it should, because all worked OK, I mean, all filesystems were correctly mounted. But anyway the info provided by me is not reliable: we used the 'mount' command from 'asmutils' and I don't know how it managed /etc/mtab. All that happened more than two years ago :(((, sorry. AFAIK, at some point of the research, the mount command from busybox was used, too. Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: About /etc/mtab and /proc/mounts 2003-02-26 9:18 ` Kasper Dupont 2003-02-26 10:26 ` Miquel van Smoorenburg 2003-02-27 4:14 ` Miles Bader @ 2003-03-02 12:51 ` DervishD 2 siblings, 0 replies; 56+ messages in thread From: DervishD @ 2003-03-02 12:51 UTC (permalink / raw) To: Kasper Dupont; +Cc: Linux-kernel Hi Kasper :) Kasper Dupont dixit: > Some more interesting cases are loopback mounts and bind mounts, > in which case the device field is completely different. [...] > (And since I remember remount > bugs in tmpfs in early 2.4 kernels, it is not going to get easier > to put more requirements on the filesystem.) Not an easy fix, then. I've read the thread that this message originated, and I think that the better solucion, in the short term I mean, is to symlink /etc/mtab to a proper writeable place in the filesystem. Anyway, I think that this kind of 'traditional' things should go away and better solutions used instead. My particular problem is that *I* don't have better solutions (at least implemented...). Thanks a lot for the interest :) Raúl ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2003-03-06 23:20 UTC | newest] Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-19 11:21 About /etc/mtab and /proc/mounts DervishD 2003-02-26 9:18 ` Kasper Dupont 2003-02-26 10:26 ` Miquel van Smoorenburg 2003-02-26 11:00 ` Olaf Dietsche 2003-02-26 11:14 ` Måns Rullgård 2003-02-26 11:44 ` Kasper Dupont 2003-02-26 12:16 ` Olaf Dietsche 2003-02-26 12:34 ` Måns Rullgård 2003-02-26 13:39 ` Olaf Dietsche 2003-02-26 13:54 ` Måns Rullgård 2003-02-26 14:23 ` Olaf Dietsche 2003-02-27 4:14 ` Miles Bader 2003-02-27 6:40 ` Kasper Dupont 2003-02-27 7:03 ` Joseph Wenninger 2003-02-27 8:28 ` Kasper Dupont 2003-03-05 0:03 ` Jamie Lokier 2003-02-27 7:06 ` Miles Bader 2003-02-27 8:25 ` Kasper Dupont 2003-02-27 8:42 ` Miles Bader 2003-02-27 9:21 ` jw schultz 2003-02-27 9:49 ` Miles Bader 2003-02-27 23:33 ` Kasper Dupont 2003-02-27 12:48 ` Denis Vlasenko 2003-02-27 23:28 ` Kasper Dupont 2003-02-28 6:15 ` Denis Vlasenko 2003-03-02 13:04 ` DervishD 2003-03-02 14:16 ` Kasper Dupont 2003-03-03 1:04 ` jw schultz 2003-03-03 12:22 ` Kasper Dupont 2003-03-04 2:02 ` jw schultz 2003-03-05 12:57 ` Kasper Dupont 2003-03-06 1:18 ` jw schultz 2003-03-06 23:30 ` Kasper Dupont 2003-03-04 11:16 ` DervishD 2003-03-04 11:08 ` DervishD 2003-02-27 9:46 ` Kasper Dupont 2003-02-27 9:58 ` Miles Bader 2003-02-27 12:26 ` Gabriel Paubert 2003-02-27 7:07 ` Joseph Wenninger 2003-02-27 7:08 ` Dominik Kubla 2003-02-27 8:12 ` Kasper Dupont 2003-02-27 9:11 ` Dominik Kubla 2003-02-27 16:00 ` Horst von Brand 2003-02-27 16:31 ` Christoph Hellwig 2003-02-27 16:40 ` Dominik Kubla 2003-02-27 19:47 ` Kasper Dupont 2003-02-27 22:13 ` Valdis.Kletnieks 2003-02-27 22:31 ` Kasper Dupont 2003-02-27 23:54 ` Miquel van Smoorenburg 2003-02-28 1:37 ` Miles Bader 2003-03-02 12:53 ` DervishD 2003-03-02 14:00 ` Kasper Dupont 2003-03-04 11:02 ` DervishD 2003-03-04 12:09 ` Kasper Dupont 2003-03-04 14:53 ` DervishD 2003-03-02 12:51 ` DervishD
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).