Hello Ted,
In article <[EMAIL PROTECTED]> you wrote:
> Should we fix it today? Given that we have ext3, I'd probably answer
> no. It's a known property of ext2; we've lived with it for over ten
> years, and to add this would just slow down ext2 (which gets used
> often as benchmark standard to a
> the mouth.) It is *expected* behaviour, yes, and it is mitigated by
> two factors. (1) Metadata for ext2 is synced out every 5 seconds,
> while data is synced out every 60, so the max window for this race
> described above is 5 seconds, and in practice rarely shows up if you
> are not using fsy
> I believe the warning should go away if you mount -o sync (but then
> the filesystem will perform very slowly :-).
>
I do agree with you, Andreas and other ppl on that this is expected
behavior on ext2, and ext3 should be chosen over ext2 when such
corruptions are under consideration.
However,
On Mon, Mar 07, 2005 at 01:57:10AM -0800, Junfeng Yang wrote:
> FiSC (our FS checker) issues a warning on ext2, complaining that crash
> after fsync causes file system to corrupt. FS corrupts in two different
> ways: 1. file contains illegal blocks (such as block # -2) 2. one block
> owned by two
On Po 07-03-05 11:45:13, Jens Axboe wrote:
> On Mon, Mar 07 2005, Junfeng Yang wrote:
> >
> > Hi,
> >
> > FiSC (our FS checker) issues a warning on ext2, complaining that crash
> > after fsync causes file system to corrupt. FS corrupts in two different
> > ways: 1. file contains illegal blocks (
On Tue, Mar 08 2005, Pavel Machek wrote:
> On Po 07-03-05 11:45:13, Jens Axboe wrote:
> > On Mon, Mar 07 2005, Junfeng Yang wrote:
> > >
> > > Hi,
> > >
> > > FiSC (our FS checker) issues a warning on ext2, complaining that crash
> > > after fsync causes file system to corrupt. FS corrupts in tw
Jens Axboe wrote:
fsync on ext2 only really guarantees that the data has reached
the disk, what the disk does it outside the realm of the fs.
If the ide drive has write back caching enabled, the data just
might only be in cache. If the power is removed right after fsync
returns, the drive might not
Thanks a lot Andreas. Your message clarifies everything.
> In ext3 this case is handled because the filesystem won't reallocate the
> metadata blocks freed from file A before they have been committed to disk.
> Also, the operations on file A are guaranteed to complete before or with
> operations
On Mar 07, 2005 14:55 -0800, Junfeng Yang wrote:
> > fsync on ext2 only really guarantees that the data has reached
> > the disk, what the disk does it outside the realm of the fs.
> > If the ide drive has write back caching enabled, the data just
> > might only be in cache. If the power is remove
> fsync on ext2 only really guarantees that the data has reached
> the disk, what the disk does it outside the realm of the fs.
> If the ide drive has write back caching enabled, the data just
> might only be in cache. If the power is removed right after fsync
> returns, the drive might not get a c
On Mon, Mar 07 2005, Junfeng Yang wrote:
>
> Hi,
>
> FiSC (our FS checker) issues a warning on ext2, complaining that crash
> after fsync causes file system to corrupt. FS corrupts in two different
> ways: 1. file contains illegal blocks (such as block # -2) 2. one block
> owned by two different
Hi,
FiSC (our FS checker) issues a warning on ext2, complaining that crash
after fsync causes file system to corrupt. FS corrupts in two different
ways: 1. file contains illegal blocks (such as block # -2) 2. one block
owned by two different files.
I diagnosed the warning a little bit and it ap
12 matches
Mail list logo
