Date: Fri, 29 Jan 1999 03:54:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Cc: julian@whistle.com, jonny@jonny.eng.br, asami@cs.berkeley.edu, stable@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: softupdates on / Message-ID: <199901290354.UAA17472@usr07.primenet.com> In-Reply-To: <199901281951.RAA26420@roma.coe.ufrj.br> from "Joao Carlos Mendes Luis" at Jan 28, 99 05:51:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> #define quoting(Julian Elischer) > // On Thu, 28 Jan 1999, Joao Carlos Mendes Luis wrote: > // > Is there a strong reason for softupdates be a tunefs option, instead of > // > a mount option ? This could be easily solved by a > // > // kirk has convinsing arguments against it and "He's the man" > ^^^^^^^^^ > > I got your point, but can you list these arguments ? If it's only "he > wants it this way, god only knows why", it's allright, but if there's > a technical reason, I'd like to know. One argument is that fsck needs to be able to tell how the thing was last mounted, if it's going to do soft-updates specific things, like not fixing up the cg free list before allowing the mount. I personally don't really buy this argument, since it should be possible to synchnously update a flag in the superblock when switching states, the same way the clean flag gets updated. A second argument is that there may be dirty device buffers hung off the device vnode, and not known to the FS mounted on the device, which is an artifact of a decision a long time ago to limit the max size of a file instead of the max size of a device. It's also one of those nasty "VM alias" issues. This is stickier. Effectively, it means that there will be I/O operations pending at the time of the state change from async to softupdates. If that happens, the results can be tragic, since the dependency graph requires that all pending operations be known, such that the graph can traversed to force operations to occur in dependency order. Kirk has admitted that you can work around this problem by first unmounting and then remounting the device in the mount update operation, since doing so will result in any dirty buffers being sync'ed out, which solves the problem. This is proven in fact by the unmount/tune/remount working as expected. I personally think that this should be done, and that, further, the mount/unmount operations should be seperated from the mapping into the FS hierarchy. This would simplify a hell of a lot of things, not the least of which is the ability to change into and out of soft updates on the fly. Effectively, you would move the "mount update" out of the FS specific code, and into higher level shared code that unmounted and remounted the device. If the root/non-root mount knowledge were taken from the per FS code at the same time, the mount operation could take a mount struct as an argument. For an update, there would be no freeing and reallocation of the mount struct, like there would be in an unmount-then-mount. This all has a nice side effect of movinf the NFS export code into the common code, and fixing the NFS export issue for those FS's that can't be NFS exported currently. 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-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901290354.UAA17472>