Re: [PATCH] Breaking ext2 file size limit of 2TB

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

[-- Attachment #1: Type: text/plain, Size: 3151 bytes --]

On Sat, 2004-06-26 11:41:58 +0530, Goldwyn Rodrigues <goldwyn_r@myrealbox.com>
wrote in message <1088230318.9825981cgoldwyn_r@myrealbox.com>:
> > You're using a reserved field; how do you mean "compatible" in this
> > situation? Think of a filesystem with real files > 2TB. How will an
> > unpatched ext3fs driver handle those files? You'll only see the <2TB
> > content, right?
> 
> When I say compatible, I mean the the filesystem need not be formatted.
> All you need to do patch the kernel, and re-coompile the module/kernel,
> and remove the old module and insert the new one (if you are using ext3
> as a module).
> 
> Currently there is a function in ext3_max_size() which limits the file
> size to 2TB because of the number of blocks, namely i_blocks. 

So it's an incompatible extension, which tells me that you'll need to
set another incompatibility flag in case there's any >2TB file (like
ext3 does that when the filesystem's journal contains data).

> > May an unpatched version under any circumstances clear the high-order
> > bits of the newly introduced 64bit integer, just because it doesn't know
> > to preserve this reserved field's value?
> 
> With an unpatched version you would not be able to create a file
> greater than 2TB at all and considers that all files are below 2TB.

...but consider what's happening in the case you're first running a
patched kernel, create some >2TB files, then start an unpatched kernel
and work with those (formerly >2TB) files.

First of all, the files will look like being %= 2TB (albeit that, I
think with any >2TB file, you'd need to set an incompatibility flag so
that an unpatched ext3fs actually *refuses* to mount any FS containing a
file >2TB). What happens if you rename() such a file? What happens if
you use a pre-2TB ext2fs with it?

Sounds like an incompatible extension, so you need to mark it as one:)

> > Being unfamiliar eith ext3's internals, are there other
> > reserved/free-for-future-use fields that don't clash with the HURD?
> 
> Andreas has proposed a few fields but I want to make sure that those
> fields as well are not used.

If you were "offered" several chooses, why did you take this one, which
is used by the HURD? Were other possibilities already used for other
purposes?

> > Are you proposing a patch like this for ext2, too?
> 
> Once approved, it can be used for ext2 as well. Converting the
> current patch for ext2 would be childs play. ext2 and ext3 use
> almost the same structures (actually from my point of view, exactly
> the same but am afraid to use the word "exactly").

They're "compatible" as long as there's no data in the journal; with
data in the journal, ext3 marks itself as being incompatible ext2. This
is what >2TB filesize support probably needs to do, too.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]