Date: Mon, 19 Dec 2005 19:40:14 +0100 From: Stefan Esser <se@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: accessing NetBSD filesystem Message-ID: <43A6FE8E.9010701@FreeBSD.org> In-Reply-To: <20051218171001.GA84988@garage.freebsd.pl> References: <20051217122006.GA2758@twelvegates.homeip.net> <20051217134258.GC1706@britannica.bec.de> <20051217171029.GB14214@twelvegates.homeip.net> <AC14C9539C9A4B47D7EE4A9A@[192.168.1.5]> <20051218015418.sf2ne6sckkss0oww@webmail.spamcop.net> <20051218151616.GA4782@britannica.bec.de> <20051218171001.GA84988@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek schrieb: > On Sun, Dec 18, 2005 at 04:16:16PM +0100, joerg@britannica.bec.de wrote: > +> FFS v1 and v2 are both working. I'm using that everyday. The one part > +> which needs attention is soft updates: FreeBSD / DragonFly have it as > +> permanent flag, NetBSD as mount option. > > Interesting. In FreeBSD fsck(8) works differently for SU-enabled FS, so > having SU as a mount option won't be possible (if we want to protect our > users from a foot-shooting). > And because of the way SU works, it is possible to run background fsck, > as the only problems are unreferenced objects (inodes, blocks, etc.). No, I've been running with soft-updates as a mount option for years (starting a few months after it made it into the then -current). My patches were even accepted for later integration by Kirk McKusick after some discussion, but there was some resistance to integrate it at that time (wait for the next major release) and then because it had been a tunefs option for so long and the default had been set to "on" in sysinstall. I'm still convinced, that my solution is better than what we currently have, and that is the reason I keep on maintaining the patch on my local systems. There is no problem with fsck, since all the patch does is simulate the effect of a tunefs -n enable/disable immediately before a r/w mount of the partition. That means, that fsck sees the previous state of the softdep flag (no change of the current behaviour). Even if I mount a removable disk without soft-updates, which was not cleanly unmounted before and had soft-updates enable, fsck will see the soft-updates flag and treat the partition correctly. The next mount will set (but not necessarily change) the softdep flag in the superblock depending on the mount options in effect. That guarantees, that the drive will be correctly checked on a system without my patch, in case that should be required. My patch is without any risk and pre-dates the import of soft-updates to NetBSD (I never checked, whether they used my then long published diffs or implemented the softdep mount option themselves). I'd appreciate if my patch would be reviewed and possibly accepted for -current. It affects just a few lines of code (use the mount option instead of the flag found in the super block when mounting a drive r/w; ignore requests to turn off softdep for a drive mounted r/w). Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43A6FE8E.9010701>