Hi Miguel,
Thanks for the reply.
"What people are saying"? So instead of understanding and solving some issue
I was just a little worried at the response from Brent earlier quote "Don't play Russian Roulette and use ext4." . The really odd thing here is that on another raid disk created the "exact" same way with the exact same parameters to "mkfs" and identically mounted I have an EXT4 filesystem with different attributes, see below. Surely that should not happen. Also as I understand it one of the defaults is to have "journal" enabled not disabled.
[root@vraid3 ~]# tune4fs -l /dev/sdc tune4fs 1.41.9 (22-Aug-2009) Filesystem volume name: <none> Last mounted on: /vraid3/vraid3 Filesystem UUID: 9e1d0cbf-f5f8-4116-9b60-a9e3c07da220 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 609484800 Block count: 2437935360 Reserved block count: 121896768 Free blocks: 2107056555 Free inodes: 609318938 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 442 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Mon Jan 18 19:16:27 2010 Last mount time: Fri Oct 1 19:38:31 2010 Last write time: Fri Oct 1 19:38:31 2010 Mount count: 1 Maximum mount count: 28 Last checked: Fri Oct 1 18:50:37 2010 Check interval: 15552000 (6 months) Next check after: Wed Mar 30 18:50:37 2011 Lifetime writes: 146 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 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 820f990d-9af5-4fb3-9e58-1c4bd504ca12 Journal backup: inode blocks
On Mon, 4 Oct 2010, Miguel Medalha wrote:
Below is the output from "tune4fs". From what people are saying it looks like et4 may not be the way to go.
"What people are saying"? So instead of understanding and solving some issue you just jump wagon, maybe only to find some other issue there?
ext4 is stable and works perfectly. You just have to configure it properly, as with anything.
Can you still recreate the filesystems? If so, study the parameters for ext4 and use them. You will want "extents", because it provides a much better use of disk space and avoids fragmentation.
As you are, you can still create a journal on the filesystem you have, using tune4fs. Look under switch -o (options).
As an example, I give you some of what I have here with a ext4 partition:
In /etc/fstab:
LABEL=/data1 /data ext4 defaults,data=journal,acl,user_xattr 1 2
tune2fs gives me the following:
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: journal_data user_xattr acl
Regards