On Mon, 10 Dec 2001, Nagy Gabor wrote:
> On 01-Dec-10 10:40, Daniel Pittman wrote:
>> OTOH, there is a little cognitive dissonance in having a journaling
>> filesystem and keeping data in memory longer: one is to increase
>> reliability at the cost of performance, the other decreases
>> reliability in return for greater performance.
> Actually, I don't think so. When I had ext2, a power failure (like
> battery drained) meant a corrupt filesystem, files/directory
> structures damaged, bad free block counts, number of inode links,
> files in lost+found.
...because the filesystem metadata was still in memory, not stored on
> With a journaling system, the stability of the fs is granted.
...once the data is committed to the journal.
> Data, i.e. the contents of files can be lost, but I don't care. What I
> care, is next time I will be able to boot, and files that I did not
> write will not be damaged.
They shouldn't be damaged in any case. If you didn't touch the file,
it's not going to be corrupted by anything other than a kernel bug.
OTOH, any directory that you modified can lose data.
> If hd spun down, and I loose half hour's typing, too bad.
If the hard drive is spun down for half an hour, *ANY* block that was
modified is still in memory. This includes metadata, just like ext2.
Assuming that you don't journal to NVRAM or something. :)
> But I will type that in again. If the fs dies, I can't rewrite it from
> scratch. Of course, if the data I write is important enough, I can
> always save, and then issue a sync command.
Well, yes. If you defeat the five second journal sync in ext3, though,
and use something like noflushd or a high bdflush interval to keep data
in RAM, you lose the reliability.
Seriously, ext3 isn't magic. If you stop it writing data to the journal,
it is exactly as reliable as ext2.
Now, if you use ext3 and block writes for half an hour, the journal will
give you an assurance that the data written half an hour ago is all on
disk. Of course, ext2 will give you exactly the same assurance.
So, ext3 will take less time to replay the journal than a full ext2 fsck
run, but that's it. No more assurance of anything. Really.
> Ps: Am I right, and there's no Reply-To header?
The list doesn't add one, so far as I can tell, and /I/ certainly
 Actually, *less* reliable, because ext2 is much better tested code
than ext3. Therefore, ext3 has a higher chance of having bugs and
corrupting your data.
 This is good, correct behavior.
In the attention economy, anyone trying to connect with an
audience must treat the user's time as the ultimate resource.
-- Jakob Neilsen
- Re: ext3
- From: Russell Coker <firstname.lastname@example.org>
- Re: ext3
- From: Nagy Gabor <email@example.com>