# ext4 with 16k block in amd64

## dbishop

Hi all

I am working with some hardware that uses ext4 with 16k blocks. This appears to be unmountable in ..x86.. kernels without using fuse.  There seems to be some fuse tools out there, like fuse-ext2 and os-fuse-umfuse-ext2 but not sure if these are safe for read/write and won't break anything.  Are there any other work-arounds? it seems there are no official or overlay packages available for fuse-ext2 or os-fuse-umfuse-ext2 and both carry a pretty ominous write-support warning...

In case it helps, this is the file system I am trying to mount

```
gentoo ~ # dumpe2fs -h /dev/md127

dumpe2fs 1.42.12 (29-Aug-2014)

Filesystem volume name:   <none>

Last mounted on:          /mnt/XC_RAID1

Filesystem UUID:          8b7c58a0-9116-4ce6-a799-5eccd669daf5

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Filesystem flags:         unsigned_directory_hash 

Default mount options:    (none)

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              234258816

Block count:              234423040

Reserved block count:     0

Free blocks:              230745053

Free inodes:              234258804

First block:              0

Block size:               16384

Fragment size:            16384

Reserved GDT blocks:      122

Blocks per group:         65528

Fragments per group:      65528

Inodes per group:         65472

Inode blocks per group:   1023

RAID stride:              8192

RAID stripe width:        131072

Flex block group size:    16

Filesystem created:       Wed Mar 11 10:41:47 2015

Last mount time:          Wed Dec 31 19:00:20 1969

Last write time:          Wed Mar 11 20:39:56 2015

Mount count:              2

Maximum mount count:      24

Last checked:             Wed Mar 11 10:41:47 2015

Check interval:           15552000 (6 months)

Next check after:         Mon Sep  7 10:41:47 2015

Lifetime writes:          56 GB

Reserved 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

Default directory hash:   half_md4

Directory Hash Seed:      c25a474f-de43-b920-e3bb-4c894bb8fbf2
```

I am always grateful for help received  :Smile: 

----------

## dbishop

All,

Solved this myself.  I grabbed os-fuse-umfuse-ext2-master.zip from github, installed it the old-fashioned way, ad viola!

Then this to mount file system as rw:

```
sudo fuse-ext2 -o rw+ /dev/md127 /mnt/raid
```

FWIW, it is actually a 4-disk SSD-based software raid level 0 with an ext4 file system, no journaling, 16K blocks

I haven't done any extensive testing of it yet, other than some basic stuff, but it seems functional.

----------

## Hu

Would you mind posting your umfuse ebuild for the benefit of anyone else who needs to access such a device?

----------

## dbishop

Yeah I'd be happy to do that, but for two things:

1. ebuilds are kinda voodoo to me, it is a language variant I'd like to master, but really I lack the specific skill (more precisely, the time to develop it). I maintain some local ebuilds for my own stuff, but those are not production-worthy efforts.

2. I have discovered that if you use the df command when one of these file systems are mounted, you have to hard-power-cycle your machine to get it back. The thread will lock and rail whatever cpu core is running the thread, and I have found no trick (other than a kernel reload) that will get it back.  Publishing an ebuild before the original coder fixes this issue (or df gets fixed) would probably result in hate mail and hardmasking anyway.

Further to (2) above, I did write a shell script that watches for this problem and sidesteps it by calling df on a per-mount basis and fills in the ext*-16k (relies on lsblk and blkid).  du doesn't seem to have a problem, just df. Anyway, I aliased the df command in /etc/bashrc just to make sure the real df only runs when it is safe, otherwise t runs the workaround script.

----------

