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
  • 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, 2013 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. Apr 24, 2013 at 13:22
  • @HaukeLaging - Have added that output, thanks :)
    – John Hunt
    Apr 24, 2013 at 13:31
  • See superuser.com/a/246756/116326
    – jofel
    Apr 24, 2013 at 13:48
  • @jofel that doesn't actually offer a solution, just a vague reasoning.
    – John Hunt
    Apr 24, 2013 at 13:52

2 Answers 2


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/

  • 2
    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, 2013 at 15:03
  • 1
    Thank you! I was able to access a Seagate Central NAS drive this way.
    – Tobia
    Sep 2, 2015 at 20:45
  • I try this way on 2 machines (kubuntu 14.04 x86 and 15.10 x64), but get freezing and CPU usage 100% by fuseext2 on open mount folder. Can me anybody say, why? Feb 11, 2016 at 13:29
  • I'm getting a similar experience to YShinkarev - hanging when trying to access the fuseext2 mount, also freezes when I try to umount it. Ctrl+c has no effect... Jul 26, 2017 at 17:34
  • 3
    While this does not answer the question per se, you can recover the data using debugfs /dev/sdXX where you can run basic commands such as ls and rdump to copy the files to a safe location. Source: n-dimensional.de/blog/2012/05/01/wd-mybook-live-data-rescue I used this method because the fuseext2 freezes (bugs.debian.org/cgi-bin/bugreport.cgi?bug=776248)
    – Alecz
    Oct 6, 2017 at 15:04

Some folks have experienced lockups with fuseext2, so here's an alternative:

debugfs /dev/sdb4

debugfs opens a CLI. rdump <directory> <target> will recursively copy an entire directory from the disk's filesystem to the host filesystem. For example, rdump home /tmp will copy the disk's /home directory to /tmp/home.

  • I did not get lockups with fuse-ext2. I was unable to mount at all. There was no error/debug output or logging either. Tried latest release from 2018 and also built from source using latest git branch. Thankfully, debugfs works perfectly fine, which is to be expected since it was created by one of the ext4 developers.
    – Snake
    Jun 29, 2021 at 3:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .