Hi All,
When a couple of EXT4 filesystems are mounted in a server I get the message
Oct 1 18:49:42 sraid3 kernel: EXT4-fs (sdb): mounted filesystem without journal Oct 1 18:49:42 sraid3 kernel: EXT4-fs (sdc): mounted filesystem without journal
in the system logs.
My confusion is why are they mounted without a journal? They were both created with
mkfs -t ext4 /dev/sdb mkfs -t ext4 /dev/sdc
and mounted in "/etc/fstab" with
/dev/sdb /sraid3 ext4 defaults 1 2 /dev/sdc /sraid4 ext4 defaults 1 2
both are 11T and so I would prefer as much stability as possible, io performance is not an issue on either device just integrity so I thought the journal would be default and necessary.
Any thoughts would be much appreciated.
Steve
Can you give us the output of "tune4fs -l /dev/sdb" ?
Does it show " has_journal" under "Filesystem features"?
If it doesn't, you can input the following:
tune4fs -o journal_data
The option "journal_data" fits the case in which you don't care about the fastest speed but you put your focus on data integrity instead.
By the way, if you only used the defaults when creating the ext4 filesystems, I am afraid that you didn't use the ext4 specific features that give it a real advantage over ext3. Some of them cannot be configured latter, they have to be specified when you create the filesystem.
Hi,
Below is the output from "tune4fs". From what people are saying it looks like et4 may not be the way to go.
[root@sraid3 ~]# tune4fs -l /dev/sdb tune4fs 1.41.9 (22-Aug-2009) Filesystem volume name: <none> Last mounted on: /sraid3/sraid3 Filesystem UUID: adc08889-f6a9-47c6-a570-e51c480240a3 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 731381760 Block count: 2925527040 Reserved block count: 146276352 Free blocks: 499285087 Free inodes: 730894437 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 326 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Filesystem created: Wed Feb 10 14:49:46 2010 Last mount time: Fri Oct 1 18:49:29 2010 Last write time: Mon Oct 4 01:32:34 2010 Mount count: 3 Maximum mount count: 37 Last checked: Mon Jun 7 15:51:57 2010 Check interval: 15552000 (6 months) Next check after: Sat Dec 4 14:51:57 2010 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: 78a52c1a-0e24-4e94-b1dc-e193e7cac68d
On Mon, 4 Oct 2010, Miguel Medalha wrote:
Can you give us the output of "tune4fs -l /dev/sdb" ?
Does it show " has_journal" under "Filesystem features"?
If it doesn't, you can input the following:
tune4fs -o journal_data
The option "journal_data" fits the case in which you don't care about the fastest speed but you put your focus on data integrity instead.
By the way, if you only used the defaults when creating the ext4 filesystems, I am afraid that you didn't use the ext4 specific features that give it a real advantage over ext3. Some of them cannot be configured latter, they have to be specified when you create the filesystem.
Steve
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
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
I was just a little worried at the response from Brent earlier quote "Don't play Russian Roulette and use ext4." .
Maybe he was referring to some old information dating back to the development period.
ext4 has been declared stable by the kernel people. As a matter of fact it is now the default filesystem for several major Linux distros.
On Tue, Oct 5, 2010 at 12:02 AM, Miguel Medalha miguelmedalha@sapo.pt wrote:
I was just a little worried at the response from Brent earlier quote "Don't play Russian Roulette and use ext4." .
Maybe he was referring to some old information dating back to the development period.
ext4 has been declared stable by the kernel people. As a matter of fact it is now the default filesystem for several major Linux distros.
That's right.
ext4 is also the default filesystem of the upcoming RHEL 6 release.
We have many servers running with ext4 and ext4 is working perfectly without any problems.
Best regards,
Morten
On 10/04/2010 02:52 PM, Steve Brooks wrote:
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.
The defaults are determined by /etc/mke2fs.conf. If you've modified or removed that file, mkfs.ext4 will behave differently.
Hi,
The "/etc/mke4fs.conf" is below. This file has never been edited by me or anyone else.
[defaults] base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr blocksize = 4096 inode_size = 256 inode_ratio = 16384
[fs_types] ext3 = { features = has_journal } ext4 = { features = has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize inode_size = 256 } ext4dev = { features = has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize inode_size = 256 options = test_fs=1 } small = { blocksize = 1024 inode_size = 128 inode_ratio = 4096 } floppy = { blocksize = 1024 inode_size = 128 inode_ratio = 8192 } news = { inode_ratio = 4096 } largefile = { inode_ratio = 1048576 blocksize = -1 } largefile4 = { inode_ratio = 4194304 blocksize = -1 } hurd = { blocksize = 4096 inode_size = 128 }
On Mon, 4 Oct 2010, Miguel Medalha wrote:
The defaults are determined by /etc/mke2fs.conf. If you've modified or removed that file, mkfs.ext4 will behave differently
On my CentOS 5.5 systems, defaults for ext4 reside on "/etc/mke4fs.conf".
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Anyone know ORACLE support EXT4 or not?
--- 10/10/5 (二)，Steve Brooks steveb@mcs.st-and.ac.uk 寫道：
寄件者: Steve Brooks steveb@mcs.st-and.ac.uk 主旨: Re: [CentOS] EXT4 mount issue 收件者: "CentOS mailing list" centos@centos.org 日期: 2010年10月5日,二,上午5:24
Hi,
The "/etc/mke4fs.conf" is below. This file has never been edited by me or anyone else.
[defaults] base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr blocksize = 4096 inode_size = 256 inode_ratio = 16384
[fs_types] ext3 = { features = has_journal } ext4 = { features = has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize inode_size = 256 } ext4dev = { features = has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize inode_size = 256 options = test_fs=1 } small = { blocksize = 1024 inode_size = 128 inode_ratio = 4096 } floppy = { blocksize = 1024 inode_size = 128 inode_ratio = 8192 } news = { inode_ratio = 4096 } largefile = { inode_ratio = 1048576 blocksize = -1 } largefile4 = { inode_ratio = 4194304 blocksize = -1 } hurd = { blocksize = 4096 inode_size = 128 }
On Mon, 4 Oct 2010, Miguel Medalha wrote:
The defaults are determined by
/etc/mke2fs.conf. If you've modified or
removed that file, mkfs.ext4 will behave
differently
On my CentOS 5.5 systems, defaults for ext4 reside on
"/etc/mke4fs.conf".
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Dr Stephen Brooks
http://www-solar.mcs.st-and.ac.uk/ Solar MHD Theory Group Tel :: 01334 463735 Fax :: 01334 463748 E-mail :: steveb@mcs.st-andrews.ac.uk
Mathematical Institute North Haugh University of St. Andrews St Andrews, Fife KY16 9SS SCOTLAND
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 4 Oct 2010, Miguel Medalha wrote:
Filesystem state: not clean
You should really look at that line and at why it is there.
Thanks again Miguel,
Yep I have mounted the filesystems as read only for the time being. I am inclined to move the data and rebuild the filesystem from scratch as the output from "tune4fs" seems to indicate that the EXT4 filesystem has many important attributes missing.
Steve
As a test, I just created an ext4 file system using the defaults, i.e. 'mkfs.ext4 -L test1 /dev/sdb1' and it has the following features, how did your's get so lean:
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
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Miguel Medalha Sent: Monday, October 04, 2010 4:41 PM To: Steve Brooks Cc: CentOS mailing list Subject: Re: [CentOS] EXT4 mount issue
Filesystem state: not clean
You should really look at that line and at why it is there.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
In the two 11T EXT4 filesystems (raid level 6), referred to inprevious posts, built on devices
/dev/sdb /dev/sdc
tune4fs listed the filesystem state as "not clean". I remounted them as read only while I decided what to do. The next day I check them again and "tune4fs" reports the filesystem state as "clean". Could this be normal behaviour?
Steve
On 10/05/2010 12:50 PM, Steve Brooks wrote:
tune4fs listed the filesystem state as "not clean". I remounted them as read only while I decided what to do. The next day I check them again and "tune4fs" reports the filesystem state as "clean". Could this be normal behaviour?
Yes. "not clean" is fine. A mounted FS without a journal will always be "not clean".
"not clean with errors" is a cause for concern.
Thanks Gordon .. a relief .. I am still inclined to move data and rebuild with all the current default EXT4 attributes.
Steve
On Tue, 5 Oct 2010, Gordon Messmer wrote:
On 10/05/2010 12:50 PM, Steve Brooks wrote:
tune4fs listed the filesystem state as "not clean". I remounted them as read only while I decided what to do. The next day I check them again and "tune4fs" reports the filesystem state as "clean". Could this be normal behaviour?
Yes. "not clean" is fine. A mounted FS without a journal will always be "not clean".
"not clean with errors" is a cause for concern. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 4 October 2010 20:07, Steve Brooks steveb@mcs.st-and.ac.uk wrote:
both are 11T and so I would prefer as much stability as possible, io performance is not an issue on either device just integrity so I thought the journal would be default and necessary.
Any thoughts would be much appreciated.
My two pence would be to switch to XFS then, much more stable (not that ext4 is particularly unstable, but XFS is rock, IMO).
-
Gordon Messmer -
James Bensley -
John R Pierce -
mcclnx mcc -
Miguel Medalha -
Mike Hanby -
Morten P.D. Stevens -
Steve Brooks