| View previous topic :: View next topic |
| Author |
Message |
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
 Posted: Thu Mar 12, 2015 1:35 am Post subject: ext4 with 16k block in amd64 |
 |
|
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
| Code: | 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  |
|
| Back to top |
|
 |
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Thu Mar 12, 2015 5:03 am Post subject: |
|
|
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:
| Code: | | 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. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23193
|
| Posted: Fri Mar 13, 2015 12:59 am Post subject: |
|
|
| Would you mind posting your umfuse ebuild for the benefit of anyone else who needs to access such a device? |
|
| Back to top |
|
|
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Thu May 21, 2015 3:45 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
