32k Blocksize Support (Ext2/Ext3)

Has this basic functionality been included in GParted yet? Original posters dilemma is easily solved using one of the freeware ext2 installable file systems on a vista system, the one I used (I forget the exact one as the laptop I used has long since ceased to be) recognised the non-standard but perfectly legal 32k block size on the data partition. Personally I coppied over all the DVR files to a new larger drives data partition and the smaller standard ext2 partions contents too.

My DVR's internal linux based firmware has an upper limit on the partition sizes it will create so although a 500G plus drive may be used, only 327.7GB is usable if the internal firmware formats the disk. As an experiment I created normal ext2 partions on a 500G drive, using all available space and the DVR reported te full space and made it available BUT table space is allocated based on the designed 32K block size and when a 4K block size is used it causes some table to overflow under certain circumstances and results in a spontaneous reboot as data gets corrupted. Also the smaller block size increases the suceptability to file fragmentation which is very undesirable on embeded devices like DVR's that do not have access to defragmentation tools.

how much work would be involved in getting GParted to recognise perfectly legal but non-standard 16K, 32K and 64K block sizes?

My assumption is that Gparted does not rely on the host liveCD linux kernels file system to parse the ext* partition structure since the partions need to be unmounted in order for GParted to be able to manipulate them and does not require the kernel to be patched to be able to mount the larger than normal block sized ext* filesystems.

Surely it'd be a relatively simple matter of permitting any legal block size that does not break file systems bitfield definition widths i.e. upto 64K block sizes... Permit resize of existing partitions and cease falsely declairing them to be invalid partitions.

Ideally it would be prefect if the create ext2 partition function would permit customisable block size, with an "are you sure?" prompt if the end user defines a legal block size that a non-patched kernel will probably fail to recognise, but bow to the users instructions if the user is sure.

Hi gedakc,
Ah I see, it's a front end for the pre-existing package... looks like the 4K standard block size limit was an x86 architecture 4k memory paging limit, presumably quicker/more efficient CPU cache use to page virtual address space than to block move chunks of data flushing other important data out of level 1/2 caches without good reason.
I have the live image... need to get together all the hardware to re-attempt this, basically re-visiting something I gave up on a few years ago as I was too busy to delve into source code and create my own build environments... and tired of waiting for comercial dimdoze products claiming support for ext2fs partition manipulation to catch up.

As these packages are open source I'd be willing to roll up my sleeves and get stuck into the source code if the restrictions placed upon the partitioning tools with oversized blocks is an arbitary limit the developers have imposed or if it's because the host linux system has not had the pre-existing patch ( http://lwn.net/Articles/249169/ ), that allows it to support oversized blocksizes, applied to it during the original distro build.
Thanks for the reply.

Ok, done a few experimental runs and have a several logs/ screen captures... Firstly the windoze ext?fs package

http://www.ext2fsd.com/?page_id=25

mounts both normal ext2 partions fine under windoze vista, sadly it cannot create partitions or resize them.

Gparted all versions tried report same errors due to underlying linux not supporting 32Kbyte block/superblock sizes.

e.g:
GParted 0.5.1

Libparted 2.2

Grow /dev/sda2 from 305.18 GiB to 698.44 GiB  00:00:01    ( ERROR ) 
     calibrate /dev/sda2  00:00:00    ( SUCCESS ) 
     path: /dev/sda2
start: 417690
end: 640431224
size: 640013535 (305.18 GiB) 

check file system on /dev/sda2 for errors and (if possible) fix them  00:00:01    ( ERROR ) 
     e2fsck -f -y -v /dev/sda2 
     e2fsck: Superblock invalid, trying backup blocks...

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

e2fsck 1.41.11 (14-Mar-2010)
e2fsck: The ext2 superblock is corrupt while trying to open /dev/sda2

========================================
and check and repairs gparted_details.htm

GParted 0.5.1

Libparted 2.2

Check and repair file system (ext2) on /dev/sda2  00:00:01    ( ERROR ) 
     calibrate /dev/sda2  00:00:00    ( SUCCESS ) 
     path: /dev/sda2
start: 417690
end: 640431224
size: 640013535 (305.18 GiB) 

check file system on /dev/sda2 for errors and (if possible) fix them  00:00:01    ( ERROR ) 
     e2fsck -f -y -v /dev/sda2 
     e2fsck: Superblock invalid, trying backup blocks...

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

e2fsck 1.41.11 (14-Mar-2010)
e2fsck: The ext2 superblock is corrupt while trying to open /dev/sda2 

same results in current live cd version and in latest ubuntu 32 and 64bit desktop live cd's

Oddly an old partition magic 8 under bartPE came close to understanding the filesystem... but not quite...

below is excerpt from its PQ_DEBUG.TXT which tells some info on the two ext partitions on the Digital Video Recorders drive.

========================================================================
Boot Sector for drive F: Drive 1, Starting Sector: 63, Type: Ext-2
========================================================================
Ext-2 file system super block:
1. Inodes count:            704
2. Blocks count:            52203
3. Reserved blocks count:   0
4. Free blocks count:       47451
5. First data block:        0
6. Log2 of block size in k: 2 (4096 bytes/block)
7. Log2 of frag. size in k: 2 (4096 bytes/fragment)
8. Blocks/group:            32768
9. Fragments/group:         32768
10. Inodes/group:           352
11. Mount time:             0x4FAF1984
12. Last write time:        0x4FAF1CCD
13. Mount count:            3
14. Max. mount count:       1000
15. Magic number:           0xEF53
16. State:                  0x0001
17. Error behavior:         0x0001
18. Minor revision level:   0
19. Last check time:        0x4FAED8F9
20. Max. time bet. checks:  0
21. Creator oper. system:   0
22. Major revision level:   1
23. Reserved block def. UID:0x0000
24. Reserved block def. GID:0x0000

========================================================================
Boot Sector for drive G: Drive 1, Starting Sector: 417690, Type: Ext-2
========================================================================
Ext-2 file system super block:
1. Inodes count:            117504
2. Blocks count:            10000211
3. Reserved blocks count:   0
4. Free blocks count:       550447
5. First data block:        0
6. Log2 of block size in k: 5 (32768 bytes/block)
7. Log2 of frag. size in k: 5 (32768 bytes/fragment)
8. Blocks/group:            65536
9. Fragments/group:         65536
10. Inodes/group:           768
11. Mount time:             0x00000001
12. Last write time:        0x00000001
13. Mount count:            1
14. Max. mount count:       1000
15. Magic number:           0xEF53
16. State:                  0x0001
17. Error behavior:         0x0001
18. Minor revision level:   0
19. Last check time:        0x00000000
20. Max. time bet. checks:  0
21. Creator oper. system:   0
22. Major revision level:   1
23. Reserved block def. UID:0x0000
24. Reserved block def. GID:0x0000

This I know and I did say "I have the live image... " and implied I would try that once I got the hardware together again.

I quote from my previous post "Gparted all versions tried report same errors due to underlying linux not supporting 32Kbyte block/superblock sizes."

I used the ubuntu releases to export the htm reports from simply because I could not be hassled to mount a flash drive or real hard drive using the command shell which we are forced to do in your live CD release which is also included in the "all versions" the contents, bar the version numbers, is the same.

Effectively the 2nd Ext2 partition is what may be found created by an IA64 linux distribution as that CPU is not crippled by the single 4k paging schema that x86 CPU linux is plagued with. Easus partition manager is able to accept the 32k blocksize and browse it but it does not resize Ext2/3 filesystems. Its linux based recovery CD version also behaves the same.

To me it does not make sense that the 3rd party filesystem manipulatipn tools would be crippled by x86 paging limits imposed upon the kernel ext2fs drivers... i'd have thought they treat the partitions as a large block of LBA sectors and work from those to create, or manipulate the filesystems unmounted so away from any paging scheme restrictions.

I have read that at least one netgear NAS also uses 32Kbyte blocks in their Ext3 filesystem much to many peoples annoyances, my guess it's a method to lock end users into their firmware and discourage hacking other linux distros to run in them.