Subject: Re: ext2fs woe on -current
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
From: Jaromir Dolecek <jdolecek@per4mance.cz>
List: current-users
Date: 12/08/1998 14:07:01
Michael Richardson wrote:
> 
>   Upgrade. The fix is in and it works well. A one liner...

Yeah, it is (I found the bug before I upgraded).

Anyway - interesting point about ext2fs_sync():
The code is very similar to ffs_sync(). In sync loop, vget() is called
for each "dirty" vnode to lock it.  If the vnode is busy (some other process
writing to it), vget() returns with EBUSY. In both ffs_sync() and "old"
ext2fs_sync(), the error is ignored - the only handled error is
ENOENT, which re-starts sync() loop. So when vget() returns EBUSY,
it's ignored and we get nice panic later, when vput() aka VOP_UNLOCK()
is called - the vnode is locked by other process. It works that way
with ext2fs at least, but there is no panic for ffs.  I spent
quite a big time just by looking for difference between ffs & ext2fs
code, which make it work under ffs (and didn't find any, unfortunately).

Another point: maybe it would be worth to actually (physically)
share more code between ffs/ufs/ext2fs. Something similar to way
ffs and lfs are sharing code in ufs_readwrite.c, maybe (not that
I like the way it's done there very much). I noticed even come parts from
ext2fs_readwrite.c are more or less a copy of ufs_readwrite.c code,
just with slightly other structure names.

Take care

-- 
Jaromir Dolecek <dolecek@ics.muni.cz>	http://www.ics.muni.cz/~dolecek/
-------------------------------------------------------------------------
It is better never to have been born.  But who among us has such luck?
One in a million, perhaps.