Subject: Re: misc/36508: Init scripts to enable mounting from read only
To: None <misc-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Adam Hoka <adam.hoka@gmail.com>
List: netbsd-bugs
Date: 07/03/2007 12:50:02
The following reply was made to PR misc/36508; it has been noted by GNATS.
From: Adam Hoka <adam.hoka@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: <jlam@pkgsrc.org>
Subject: Re: misc/36508: Init scripts to enable mounting from read only
filesystems
Date: Tue, 3 Jul 2007 14:46:33 +0200
On Thu, 28 Jun 2007 22:25:02 +0000 (UTC)
"Johnny C. Lam" <jlam@pkgsrc.org> wrote:
> The following reply was made to PR misc/36508; it has been noted by GNATS.
>
> From: "Johnny C. Lam" <jlam@pkgsrc.org>
> To: gnats-bugs@NetBSD.org
> Cc: netbsd-bugs@netbsd.org
> Subject: Re: misc/36508: Init scripts to enable mounting from read only filesystems
> Date: Thu, 28 Jun 2007 22:20:46 +0000
>
> I don't think these scripts will be good in the general case.
Let`s assume you have some hardware problems (or some other reason, you cant prepare for), and you can only mount your drive as read only.
You will have suddenly an unusably system. (if its starting at all) And you have to find a solution manualy, which is a waste of time. :)
These scripts check if /var and /tmp should be already writable, and they are not they provide a temporaly space for logs and lease files for example.
> Take the case of /var. It is almost certainly a critical file system
> to mount, and so must really be done either within mountcritlocal or
> as a script that REQUIRES root and is BEFORE mountcritlocal.
The script dont know if there will be usable filesystem after mouncritlocal (which would be in normal case)
> I don't think the suggestion to populate /var "only sometimes" makes
> sense. I understand the difficulty where /var needs to be mounted
> extremely early and one can't rely on the presence of utilities stored
> on /usr, e.g. mtree, chown, chgrp, etc., to help with populating /var.
>
> Why not create a "mountvar" script that REQUIRES root and is BEFORE
> mountcritlocal that has an additional action "create" that creates
> a .tar file on the root filesystem? Then the "start" action could
> mount the tmpfs filesystem onto /var and then just extract the .tar
> file directly into /var using /bin/pax. This avoids any problems
> with not having /usr mounted at boot time.
>
> The "mounttmp" script should probably grow the option to just symlink
> /tmp to /var/tmp and avoid needing two separate tmpfs mounts for both
> n /var and /tmp. the cases where one might want to deal with read-only
> root, e.g. for an embedded device, symlinking /tmp to /var/tmp is
> fairly common. I would guess the "mounttmp" script would REQUIRE
> mountvar and is BEFORE mountcritlocal.
If someone wants to really use it in embedded environment, he wont use the defaults but a costumised environment for the task.
This is why its embedded use. :)
It`s some kind of a fault tolerancy/sanitiy check, not a complete solution. So please think about it that way.
> I do think that these "mountvar" and "mounttmp" scripts should be just
> incorporated directly into the mountcritlocal script.
I just put them as separate scripts because the original implementation did it this way
They could be part of the mountrcrit scripts. But I think they are good that way.
thanks for the comment
--
Adam