Re: [RFC] extents support for EXT3

[Alex Tomas <bzzz@tmi.comex.ru>]

>>>>> Ed Sweetman (ES) writes:

 ES> I was testing this with only a single partition mounted with extents
 ES> enabled when benchmarking.  Ext3 gave no messages of being mounted
 ES> afterbootup with or without extents so to make sure i had extents
 ES> enabled i booted with all my partitions with the extents option.  I
 ES> suspect then my problems began.  I'm completely unaware of the extent
 ES> of the damage enabling extents has done since most of the important
 ES> things were opened, not created during my extents use.  In any case it
 ES> may be that the reason why init is not able to be found is because i
 ES> used apt and upgraded my system ...and I dont remember if i had
 ES> extents enabled at the time or not.  If my init is in extents format
 ES> though, then why is a patched kernel able to read it with extents not
 ES> being enabled via the omunt option where as kernels without the patch
 ES> cannot.  Is extents able to be read from a fs even when it's not
 ES> mounted with the option but not written?   I'm kinda confused, this
 ES> aspect of extents wasn't in the original email.

well, on my testbox I use _patched with extents_ ext3 as / and /boot partitions.
I haven't seen any problems on them. with patch, ext3 look at special EXTENTS
flag in inode (this flag is set up only for newly created files on fs being
mounted with extents enabled) and calls apropriate routines. thus, it will
call extents routines for those file even if fs is being mounted with extents
disabled. I really do believe that your root filesystem haven't been mounted
with extents enabled, so init must be stored in good old format.

 ES> i'm going to try and boot a kernel without the extents patch (so far
 ES> hasn't been possible) and run dbench again and see if i get different
 ES> numbers.  I'm almost suspecting extents being enabled no matter what i
 ES> mount the fs's as.

that would be fine!