Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a 3TB hard disk pulled out of a WD Mybook Live NAS. The partition table is as follows:

Model: ATA WDC WD30EZRS-11J (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 3      15.7MB  528MB   513MB                primary
 1      528MB   2576MB  2048MB  ext3         primary  raid
 2      2576MB  4624MB  2048MB  ext3         primary  raid
 4      4624MB  3001GB  2996GB  ext4         primary

So I'm trying to access partition 4 (the big one!):

root@john-desktop:~/linux-3.9-rc8# mount -t ext4 /dev/sdb4 /mnt/
mount: wrong fs type, bad option, bad superblock on /dev/sdb4,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Dmesg output:

[ 2058.085881] EXT4-fs (sdb4): bad block size 65536

This is fair enough. As far as I can tell my kernel isn't configured to support block sizes of over 4K.

My question is, what symbol should I be searching for in my kernel config to allow bigger block sized partitions to be mounted? I've scoured google for this, and I thought I saw the option before but I can't find any mention of it in the latest stable kernel source.

Edit: Full hard disk info from hdparm here: http://pastebin.com/hDdbUzjd

Edit: dumpe2fs output:

Mount count:              0
Maximum mount count:      30Last checked:             Wed May 30 15:22:14 2012Check interval:           15552000 (6 months)Next check after:         Mon Nov 26 14:22:14 2012Lifetime writes:          319 GBReserved blocks uid:      0 (user root)Reserved blocks gid:      0 (group root)First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      cd7a28a0-714c-9942-29f4-83bca1209130
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             2048M
Journal length:           32768
Journal sequence:         0x00010146
Journal start:            0
share|improve this question
    
Please note, passing a block size to the mount command does nothing: mount -t ext4 -o bs=65536 /dev/sdb4 /mnt .... the bs option is only supported on a handful of filesystems (and not ext ones..) –  John Hunt Apr 24 '13 at 13:09
    
What is the dumpe2fs -h output for that volume? My 2012 man page for mke2fs says: "Valid block-size values are 1024, 2048 and 4096 bytes per block." Quite a jump from 4096 to 65536. –  Hauke Laging Apr 24 '13 at 13:22
    
@HaukeLaging - Have added that output, thanks :) –  John Hunt Apr 24 '13 at 13:31
    
See superuser.com/a/246756/116326 –  jofel Apr 24 '13 at 13:48
    
@jofel that doesn't actually offer a solution, just a vague reasoning. –  John Hunt Apr 24 '13 at 13:52
show 2 more comments

1 Answer 1

Woohoo, I solved it :)

The short answer is you can't mount >4k block size devices on x86 linux machines as far as I can tell without some serious kernel hacking.

However, there is a work around.. using fuse-ext2 to mount the disk:

fuseext2 -o ro -o sync_read /dev/sdb4 /mnt/

(you'll probably need to apt-get fuseext2 first..)

works perfectly first time!

This is basically going to be how people can recover their MyBook Live disks.

Howto blog post here: http://john-hunt.com/2013/04/25/recovering-data-from-a-wd-mybook-live-2tb-3tbor-similar/

share|improve this answer
    
Yea, the kernel page cache limits block size to the CPU's page size, so for i386/amd64, you can't mount a fs with more than 4k block size. Another alternative is to use e2tools. –  psusi Apr 25 '13 at 15:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.