>> If you ran e2fsck after the each system crash, it would have detected
>> any doubly allocated files and offered to clone the data blocks to avoid
>> this problem.
This is not a new filesystem, only a patch to refine ext2fs.
Meaningless "-o sync" made me sad, so I decided to implement them.
>> According to the web page, the patches require that you run e2fsck
>> anyway, because the patch doesn't guarantee the consistency of the
>> allocation bitmaps. So if you didn't run e2fsck after the crash, that
>> could easily explain why your makefile got corrupted (the block bitmap
>> shows the block as being unallocated, and then that block got grabbed
>> when some other binary file was allocated).
Yes, e2fsck is required. Standard ext2fs mounted "sync" also requires it.
(Of course I have another implementation that does not need e2fsck after
a crash at all - free from fsck.)
I've read all of your e2fsck, e2fsck tries to correct filesystem as possible,
you did great works!.
I know correcting bitmaps, superblock and block group descriptors are perfect,
but correcting others are not perfect yet, there are some kind of assumption
to repair them. (almost perfect but not truely perfect)
And another important point of this patch is guaranteeing results of
systemcalls.
If a file was fsynced, the file must be in an appropriate directory
with valid data after a crash.
If a file was removed, the file shuold not be reapear again.
This enables applications to control consistency at application level.
> E2fsck can repair this kind of filesystem consistency for you, and your
> patch doesn't obviate the need for filesystem consistency. If you must
> take the performance hit of doing synchronous updates, a bettter tactic
> to use is Kirk McKusick's Soft Updates technique, or wait for Stephen to
> get his Journalling extensions to ext2 done. They will allow you to
I know them and I'm curious about them.
But I selected the simplest way to minimize the changes and
I think it'll be useful for a few years.
These day I'm considering that it is not a bad idea that we could
abandon resources just being allocated or being freed after a crash
which machines would have a plenty disk space.
This might lead a good performance and stability in a crash without fsck.
Lastly may I suggest you?
I think it is dangerous that e2fsck repairs indirect blocks in PASS1
which might be DUPed and they would be cloned in PASS1D to avoid
this situation.
Regards,
Hirokazu Takahashi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/