Date: Mon, 11 May 1998 00:16:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: roberto@keltia.freenix.fr (Ollivier Robert) Cc: current@FreeBSD.ORG Subject: Re: Soft Updates Message-ID: <199805110016.RAA29954@usr05.primenet.com> In-Reply-To: <19980510004603.A16999@keltia.freenix.fr> from "Ollivier Robert" at May 10, 98 00:46:03 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > you need to use the -n option of tunefs on an unmounted filesystem > > it's not a mount option.. > > Why not BTW ? async/noasync are mount options so one could expect > softupdates to be the same. Is there an reason for the current scheme (not > that I mind but it would make switch it on/off easier, especially for /). The argument is that when you change a mount option on the FS, the in core buffers do not get flushed. In this case, you could have some writes pending upon which a newly scheduled soft updates write operation should depend, but since the write was scheduled before the soft updates dependency tracking was engaged, the dependency is unrecoverable. There are potentially some issues with FS metadata cached off of the device vnode, as well (this is more of a FreeBSD architectural issue that causes problems unless it is carefully addressed; among other things, maximum FS size is limited by this; otherwise the maximum FS size would be limited vy the offset size, not the maximum VM object size; you would still have a file size limited by VM object size, however). It's very possible to work around this. Specifically, the conversion of an FS from read-write to read-only effectively does an unmount followed by a mount under the covers. The reason Kirk gave for not doing this was that the "under the covers" code was rather gross and convoluted, and it would have had to have been (effectively) duplicated once again for soft updates being switched on and off. I tend to agree that the code is gross and convoluted. See my post in the "NFS exporting an MFS" thread on what could be done to the VFS ops to make this easier to deal with, work for all FS's, and in general, more robust. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805110016.RAA29954>