Simon Burge <simonb%NetBSD.org@localhost> writes: > I'm running with a complete ZFS-only setup with no legacy mounts. This > is my basic ZFS layout (leaving out a few mounts that don't add any more > value to this discussion): > > NAME MOUNTPOINT > pool0 /pool0 > pool0/ROOT none > pool0/ROOT/default / > pool0/home /home > pool0/home/simonb /home/simonb > pool0/usr /usr > pool0/usr/obj /usr/obj > pool0/usr/pkg /usr/pkg > pool0/var /var > pool0/var/crash /var/crash > pool0/var/log /var/log > pool0/var/mail /var/mail > pool0/var/tmp /var/tmp > > and I then have this grot in my mountcritlocal: > > # XXXXXX > zfs mount pool0/var > zfs mount pool0/var/crash > zfs mount pool0/var/log > zfs mount pool0/var/mail > zfs mount pool0/var/tmp [I am guessing you have a boot partition that isn't zfs, just to load the kernel, but I haven't tried to read about that, and it seems a separate topic.] I will assume that the / (zfs as you say above) is the only mounted fs as init starts. > I have been trying to think of better solutions to this before you added > this new critical_filesystems_zfs rc.conf variable. One idea was to add > a user defined property (eg "netbsd:mountcrit=yes") and use that in a > similar way to how you implemented mount_critical_filesystems_zfs . Then > another idea hit me. > > Why don't we just mount all the ZFS filesystems in mountcritlocal? I > can't think of any negative reasons for not mounting all non-legacy > mountable ZFS filesystems early in the boot process. This would be as > simple as moving this chunk from mountall to mountcritlocal: > > # Mount ZFS filesystems first because fstab > # may try and null mount paths on ZFS. > if checkyesno zfs; then > zfs mount -a > zfs share -a > fi > > and the unmount stuff from mountall to a new mountcritlocal_stop > function. [I don't really know what you mean by legacy (other than non-zfs, but you didn't say that, so perhaps you mean something different).] I think the big point here is why do we have a notion of critical filesystems, and if we are going to mount all zfs filesystems in mountcritlocal, why would we then not mount all local filesystems? AIUI, the critical notion comes from the netbooting days and sequencing of bringing up networking to mount filesystems, which can involve running programs that aren't on root. I have used mountcritlocal to mount /var and /usr so that route6d could start at the time when it is invoked by rc.d, I think, but the details have been paged out. I don't see that being a different issue with zfs for / /var /usr. Although I see it hitting more people as having multiple filesystems is a more sensible thing to do with zfs because of shared pool space. If we are going to keep the critical concept, then it seems like it should apply to all filesystems. If we are going to abandon it, that's a big discussion for tech-userlevel. > For people using critical early legacy mounts, they can still be added > via critical_filesystems_local as that looks up via /etc/fstab (right? > I haven't tested this). If you mean /var or /usr as ffs, I would expect so and certainly that's necessary to support. > Anyone see a reason for not using this much simpler approach to > having ZFS filesystems available? I don't think we'd need to keep > critical_filesystems_zfs if we change mountcritlocal as I suggest, as > that explicitly only deals with non-legacy filesystems. I don't think it's good to treat zfs and non-zfs differently and I don't think there are any good reasons to do so. I also don't think its a good idea to make ffs 2nd class. If the big thing is to avoid having to manually mark zfs filesystems as critical in rc.conf, fstab or some other file, and instead use a property, that sounds like a perfectly fine solution, as the mountpoint is already in zfs properties, and it makes sense to keep the critical bit in the same place as the mountpoint. However, I don't know how it works if you have a 2nd pool with a critical filesystem and that pool doesn't come up. (I could see somebody having RAID1 for / /var and swap and RAIDZ for /usr and everything else.) From that viewpoint listing the critical filesystems in rc.conf, leading to failure if they are not available, seems better. It also seems like perhaps pools could be marked critical vs not so that zfs startup can attach the critical pools first, and then the others, but I suspect that is a lot of work for no gain, and the rc.conf approach avoids the need. I am really uncomfortable with a plan that comes from a place of declaring anything but zfs as "legacy, that people should no longer be using". Maybe you don't mean that by using the word (and this ambiguity is a reason I don't like using the word legacy in this context at all). (I'm not at all anti zfs - I have actually set it up on one machine, and am contemplating moving my main machine to it.) Greg
Attachment:
signature.asc
Description: PGP signature