bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ext2fs 2GB limit status?


From: Marco Gerards
Subject: Ext2fs 2GB limit status?
Date: 20 Sep 2003 21:40:47 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Hi,

Ogi (I hope he is subscribed to this list) wrote some patches for the Hurd so
ext2fs can support large partitions.  It seems to me that not many
people have looked at these patches :(.  Having a >2GB capable ext2fs
is very important to me.

Today I started to study these patches, I will continue to do this
later.  So the next time I will look at it I will have a look at the
cache/libpager related parts of the patch.

I've noticed a few things while reading this patch, I will discuss
this in this mail, but please understand that I'm quite a newbie and
possibly misunderstand things.  Please correct me if I say something
stupid :).

The thing that bothered me when reading these patches was that byte
offsets were used quite often.  This will make it not possible to use
partitions bigger than 4GB in some circumstances.

These functions/macros use byte offsets:

- boffs_ptr
- bptr_offs

And these indirectly:

- record_global_poke
- sync_global_ptr
- record_indir_poke
(all use bptr_offs)
- bptr (uses boffs_ptr)

Most likely I forgot some.  Especially the pokel stuff might be bad.
Another use for these functions was to read/write the superblock;
although it isn't that bad, it would be better if you didn't use byte
offsets for this.

Perhaps this problem can be fixed by removing all these functions so
they can't be used accidently.  I see no reason to have these
functions anyway.

Another thing I've noticed in the patch were changes in the amount of
whitespaces.  This isn't a big problem (for me), it is just something
to lookout for when sending in the definite patch, here is an example:

-     * We have succeeded in finding a free byte in the block
-     * bitmap.  Now search backwards up to 7 bits to find the
-     * start of this group of free blocks.
+   * We have succeeded in finding a free byte in the block
+   * bitmap.  Now search backwards up to 7 bits to find the
+   * start of this group of free blocks.

The last thing I mentioned was this:

+#if 1
       err = find_block (node, offset, &block, &lock);
       if (err)
        break;
       assert (block);
+#else
+      /* XXX: I still haven't investigated why this is needed...  */
+      err = ext2_getblk (node, offset >> log2_block_size, 1, &block);
+      if (err)
+       break;
+#endif

I'm not really an ext2fs expert, but I think this is used for sparse
files.  Ext2fs doesn't allocate blocks when seeking, it just makes the
file sparse.  So the blocks get allocated just before they are written
to disk.

Here is an example for sparse files:

marco@marco:/tmp$ dd if=/dev/zero of=sparse_file bs=1024 count=100
100+0 records in
100+0 records out
marco@marco:/tmp$ cp --sparse=always sparse_file sparse_file2
marco@marco:/tmp$ ls -ls sparse_file*
 104 -rw-r--r--    1 marco    users      102400 Sep 20 16:50 sparse_file
   0 -rw-r--r--    1 marco    users      102400 Sep 20 16:50 sparse_file2

Do you see the 2nd file doesn't have any blocks allocated?  If you
think I'm wrong about this (and what I said was wrong), please tell
me, I will investigate this better in that case.

I also have a question about the code.  The assembly code "int $3" is
used.  AFAIK this is used to tell the debugger a breakpoint is
reached, right?  When is this function (abort) called?

Thanks,
Marco





reply via email to

[Prev in Thread] Current Thread [Next in Thread]