Hi,
> Hi,
>
> Few comments on the patches:
>
> 1) Both kernel patch and e2fsprogs doesn't seem to apply cleanly for
> the versions you mentioned. I had to fix few rejects.
Sorry. My patches were corrupted because my poor mailer had
removed spaces in the patch.
I will take care of it when I update this patch.
> 2) I am still not able to make filesystem bigger than 8TB with your
> patch. I get following message.
>
> # fdisk -l /dev/md0
>
> Disk /dev/md0: 10479.7 GB, 10479753756672 bytes
> 2 heads, 4 sectors/track, -1736433664 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
>
>
> elm3b29:~/e2fsprogs-1.38/misc # ./mke2fs /dev/md0
> mke2fs 1.38 (30-Jun-2005)
> mke2fs: Filesystem too large. No more than 2**31-1 blocks
> (8TB using a blocksize of 4k) are currently supported.
>
> When I try to create "ext3":
As I said in my previous mail, You should specify -F option to
create ext2/3 which has more than 2**31-1 blocks.
It is because of the compatibility.
> elm3b29:~/e2fsprogs-1.38/misc # ./mke2fs -t ext3 /dev/md0
> mke2fs 1.38 (30-Jun-2005)
> mke2fs: invalid blocks count - /dev/md0
>
> Were you able to test these changes ?
You should specify -j option to create ext3 as below.
# ./mke2fs -j /dev/md0
On Mar 18, 2006 14:57 +0900, Takashi Sato wrote:
> >elm3b29:~/e2fsprogs-1.38/misc # ./mke2fs /dev/md0
> >mke2fs 1.38 (30-Jun-2005)
> >mke2fs: Filesystem too large. No more than 2**31-1 blocks
> > (8TB using a blocksize of 4k) are currently supported.
> >
> >When I try to create "ext3":
>
> As I said in my previous mail, You should specify -F option to
> create ext2/3 which has more than 2**31-1 blocks.
> It is because of the compatibility.
Oh, using -F for this is highly dangerous. That would allow mke2fs to
run on e.g. a mounted filesystem or something. Instead use an option
like "-E 16tb" or something.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
On Sat, Mar 18, 2006 at 03:11:02AM -0700, Andreas Dilger wrote:
> > As I said in my previous mail, You should specify -F option to
> > create ext2/3 which has more than 2**31-1 blocks.
> > It is because of the compatibility.
>
> Oh, using -F for this is highly dangerous. That would allow mke2fs to
> run on e.g. a mounted filesystem or something. Instead use an option
> like "-E 16tb" or something.
Agreed that we shouldn't use -F, but what's the compatibility reason?
Supporting 2**31-1 blocks required bugfixes in the kernel and in
e2fsprogs, yes, but if it's not a filesystem format change, but rather
a "kernel had bugs which have now been fixed" statement, that's not
the sort of thing where I'd think forcing the system administrator to
add a magic command-line flag would be necessary or desirable.
I could see printing a warning message saying that older kernels might
have problems with this, and I could also imagine including with the
kernel patch enabling some sort of flag that could be queried, perhaps
via /sys/fs/ext3/32bit-nr-blocks so that if it isn't present, mke2fs
could give a more emphatic warning that the current kernel wouldn't be
able to deal with filesystems being created.
- Ted
On Sat, 2006-03-18 at 14:57 +0900, Takashi Sato wrote:
> Hi,
>
> > Hi,
> >
> > Few comments on the patches:
> >
> > 1) Both kernel patch and e2fsprogs doesn't seem to apply cleanly for
> > the versions you mentioned. I had to fix few rejects.
>
> Sorry. My patches were corrupted because my poor mailer had
> removed spaces in the patch.
> I will take care of it when I update this patch.
>
> > 2) I am still not able to make filesystem bigger than 8TB with your
> > patch. I get following message.
> >
> > # fdisk -l /dev/md0
> >
> > Disk /dev/md0: 10479.7 GB, 10479753756672 bytes
> > 2 heads, 4 sectors/track, -1736433664 cylinders
> > Units = cylinders of 8 * 512 = 4096 bytes
> >
> >
> > elm3b29:~/e2fsprogs-1.38/misc # ./mke2fs /dev/md0
> > mke2fs 1.38 (30-Jun-2005)
> > mke2fs: Filesystem too large. No more than 2**31-1 blocks
> > (8TB using a blocksize of 4k) are currently supported.
> >
> > When I try to create "ext3":
>
> As I said in my previous mail, You should specify -F option to
> create ext2/3 which has more than 2**31-1 blocks.
> It is because of the compatibility.
>
> > elm3b29:~/e2fsprogs-1.38/misc # ./mke2fs -t ext3 /dev/md0
> > mke2fs 1.38 (30-Jun-2005)
> > mke2fs: invalid blocks count - /dev/md0
> >
> > Were you able to test these changes ?
>
> You should specify -j option to create ext3 as below.
>
> # ./mke2fs -j /dev/md0
Okay. I tested your patches and mkfs changes.
I am able to create a >8TB filesystem and was able to
mount it :)
elm3b29:~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 79366980 76545536 2821444 97% /
tmpfs 3574032 8 3574024 1% /dev/shm
/dev/md0 9833697924 131228 9677640816 1% /mnt
I run single "fsx" tests and quickly ran into issues. fsx complained
about data mismatch :(
Here is the "dmesg" output:
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs error (device md0): ext3_new_block: Allocating block in system
zone - block = 131072
Aborting journal on device md0.
ext3_abort called.
EXT3-fs error (device md0): ext3_journal_start_sb: Detected aborted
journal
Remounting filesystem read-only
fsx-linux[15668]: segfault at fffffffffffffffb rip 00002b33b3eddda0 rsp
00007fffffef1e38 error 4
fsx-linux[15667]: segfault at fffffffffffffffb rip 00002b7736f5dda0 rsp
00007fffffb70da8 error 4
ext3_new_block: block was unexpectedly set in b_committed_data
EXT3-fs error (device md0) in ext3_reserve_inode_write: Journal has
aborted
fsx-linux[15666]: segfault at fffffffffffffffb rip 00002b0582de6da0 rsp
00007fffffd24f18 error 4
fsx-linux[15669]: segfault at 00000000ffffffff rip 00002ad94d283da0 rsp
00007fffff95aa28 error 4
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_committed_data
Thanks,
Badari
On Wed, 2006-03-22 at 15:45 -0800, Badari Pulavarty wrote:
> On Sat, 2006-03-18 at 14:57 +0900, Takashi Sato wrote:
> > Hi,
> >
> > > Hi,
> > >
> > > Few comments on the patches:
> > >
> > > 1) Both kernel patch and e2fsprogs doesn't seem to apply cleanly for
> > > the versions you mentioned. I had to fix few rejects.
> >
> > Sorry. My patches were corrupted because my poor mailer had
> > removed spaces in the patch.
> > I will take care of it when I update this patch.
> >
> > > 2) I am still not able to make filesystem bigger than 8TB with your
> > > patch. I get following message.
> > >
> > > # fdisk -l /dev/md0
> > >
> > > Disk /dev/md0: 10479.7 GB, 10479753756672 bytes
> > > 2 heads, 4 sectors/track, -1736433664 cylinders
> > > Units = cylinders of 8 * 512 = 4096 bytes
> > >
> > >
> > > elm3b29:~/e2fsprogs-1.38/misc # ./mke2fs /dev/md0
> > > mke2fs 1.38 (30-Jun-2005)
> > > mke2fs: Filesystem too large. No more than 2**31-1 blocks
> > > (8TB using a blocksize of 4k) are currently supported.
> > >
> > > When I try to create "ext3":
> >
> > As I said in my previous mail, You should specify -F option to
> > create ext2/3 which has more than 2**31-1 blocks.
> > It is because of the compatibility.
> >
> > > elm3b29:~/e2fsprogs-1.38/misc # ./mke2fs -t ext3 /dev/md0
> > > mke2fs 1.38 (30-Jun-2005)
> > > mke2fs: invalid blocks count - /dev/md0
> > >
> > > Were you able to test these changes ?
> >
> > You should specify -j option to create ext3 as below.
> >
> > # ./mke2fs -j /dev/md0
>
> Okay. I tested your patches and mkfs changes.
>
> I am able to create a >8TB filesystem and was able to
> mount it :)
>
> elm3b29:~ # df
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/hda2 79366980 76545536 2821444 97% /
> tmpfs 3574032 8 3574024 1% /dev/shm
> /dev/md0 9833697924 131228 9677640816 1% /mnt
>
> I run single "fsx" tests and quickly ran into issues. fsx complained
> about data mismatch :(
>
> Here is the "dmesg" output:
>
> EXT3 FS on md0, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> EXT3-fs error (device md0): ext3_new_block: Allocating block in system
> zone - block = 131072
> Aborting journal on device md0.
> ext3_abort called.
> EXT3-fs error (device md0): ext3_journal_start_sb: Detected aborted
> journal
> Remounting filesystem read-only
> fsx-linux[15668]: segfault at fffffffffffffffb rip 00002b33b3eddda0 rsp
> 00007fffffef1e38 error 4
> fsx-linux[15667]: segfault at fffffffffffffffb rip 00002b7736f5dda0 rsp
> 00007fffffb70da8 error 4
> ext3_new_block: block was unexpectedly set in b_committed_data
> EXT3-fs error (device md0) in ext3_reserve_inode_write: Journal has
> aborted
> fsx-linux[15666]: segfault at fffffffffffffffb rip 00002b0582de6da0 rsp
> 00007fffffd24f18 error 4
> fsx-linux[15669]: segfault at 00000000ffffffff rip 00002ad94d283da0 rsp
> 00007fffff95aa28 error 4
> __journal_remove_journal_head: freeing b_committed_data
> __journal_remove_journal_head: freeing b_committed_data
> __journal_remove_journal_head: freeing b_committed_data
More information. I ran the test with "-onoreservation" thinking that
the patch didn't address "reservation code" issues and I still ran
into block allocation problems. Hope this helps.
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs error (device md0): ext3_new_block: block(3304604584) >= blocks
count(2497616320) - block_group = 4, es == ffff8101dee44400
Aborting journal on device md0.
ext3_abort called.
EXT3-fs error (device md0): ext3_journal_start_sb: Detected aborted
journal
Remounting filesystem read-only
fsx-linux[18270]: segfault at fffffffffffffffb rip 00002b9eae932da0 rsp
00007fffffbf73d8 error 4
fsx-linux[18271]: segfault at fffffffffffffffb rip 00002aafb6ebada0 rsp
00007fffffaf0e58 error 4
fsx-linux[18272]: segfault at fffffffffffffffb rip 00002abcc19b7da0 rsp
00007fffffde6348 error 4
EXT3-fs error (device md0) in ext3_prepare_write: IO failure
__journal_remove_journal_head: freeing b_committed_data
journal commit I/O error
fsx-linux[18273]: segfault at fffffffffffffffb rip 00002b6b16724da0 rsp
00007ffffff8f5e8 error 4
Thanks,
Badari