(cc' list trimmed)
On Sat, Aug 04, 2001 at 06:04:23AM +0200, Matthias Andree wrote:
However, aren't we already at the point that ext3 fsync() flushes
the corresponding dirents?
Ideally an acceptable solution will also obvioate the needs for +S
under ext2 and also work for reiserfs and more.
How difficult would it be to have the inode track changes to its
dirents such as rename or link?
For simple cases, not terrible (I don't think), but you would have to
limit how much you tracked in extreme cases (like 2 directory inode at
most or something).
I mean, FFS + softupdates can do it.
So run FFS :)
The MTA doesn't really care for the implementation, it cares that
it never loses its files over a crash
By MTA you mean Postfix. Wietse recently stated he might start
looking at other alternatives which don't relay on undocument FFS
semantics or synchronous metadata updates.
where finding it renamed
to /mount/point/lost+found is considered a loss.
Actually, there is enough information on the file to recover things
for postfix. For sendmail (which has two files, your pretty much
stuffed though).
unlink and particularly symlink will need separate consideration,
but that's left for later.
Unlink should be ok, I don't see why symlink should even be
considered (it would make things way too complex for little or no
gain).
Anyhow, if you read recent comments it looks like thre are filesystems
which will be badly affected by placing this logic into the VFS
(eg. Coda). It may well be this should become a fs-specific thing
(which sucks a little, because it makes the suggestion of tracking
link/unlink directories ugly) and for some filesystems such as
resierfs and ext3, they could be modified to merge the 'related
directories' writes with the metadata write of the file itself.
--cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:33 EST