really strange ext4 behavior
Eric Sandeen
sandeen at redhat.com
Mon Feb 14 19:47:48 UTC 2011
On 2/13/11 12:29 PM, Dennis Jacobfeuerborn wrote:
> On 02/12/2011 11:52 PM, Ric Wheeler wrote:
>> On 02/12/2011 05:31 PM, Michał Piotrowski wrote:
>>> Hi,
>>>
>>> W dniu 12 lutego 2011 23:19 użytkownik Ric Wheeler
>>> <rwheeler at redhat.com> napisał:
>>>> On 02/12/2011 05:12 PM, Michał Piotrowski wrote:
>>>>> Hi,
>>>>>
>>>>> I added a disc to my box. I wanted to use ext4. I run fs_mark to test
>>>>> speed, to my surprise I heard a really strange noises.
>>>>>
>>>>> It's very strange because the drive is new
>>>>> 9 Power_On_Hours 0x0032 100 100 000 Old_age
>>>>> Always - 12
>>>>>
>>>>>
>>>>> # fs_mark -d test/
>>>>> [..]
>>>>> FSUse% Count Size Files/sec App Overhead
>>>>> 0 1000 51200 22.8 54347
>>>>>
>>>>> I decided to create an ext3 file system on this drive and everything works
>>>>> fine.
>>>>>
>>>>> # fs_mark -d test/
>>>>> [..]
>>>>> FSUse% Count Size Files/sec App Overhead
>>>>> 0 1000 51200 103.7 57229
>>>>>
>>>>> When I mount this ext3 fs as ext4 and run fs_mark I hear strange sounds
>>>>> again.
>>>>>
>>>>> I use F14 and self compiled kernel from rawhide 2.6.37-1.fc14.x86_64 +
>>>>> e2fsprogs-1.41.14-2.fc14.x86_64.
>>>>>
>>>>> I mount ecryptfs on top of this file system.
>>>>>
>>>>> Does anyone know what might be causing this strange ext4 behavior?
>>>>>
>>>> Hi Michael,
>>>>
>>>> fs_mark run a fsync heavy test. What you might be hearing is the impact of
>>>> the fsync's. ext4 defaults to using "write barriers" enabled, ext3 does not.
>>>> Without write barriers, those fsync push data from the box to the write
>>>> cache on the drive only. With barriers, the disk will flush that cache to
>>>> the platter, so the platter moves and you probably hear the head, etc.
>>>>
>>>> You can test if this is the cause by mouting ext4 with "nobarrier" to see if
>>>> the noise goes away.
>>> I mounted fs with nobarrier and now it works just like ext3. Thanks! This solves
>>> the riddle :)
>>>
>>
>> Good to hear that it worked!
>>
>> Note that the barrier code makes your data safer, so you should run with it on
>> by default (unless you really don't care about the file system).
>
> If ext3 was running fine without barriers for all these years why is this
> such a problem with ext4? Does ext4 do something differently that barriers
> are now required?
barriers are always required for integrity if you have a volatile write cache;
this is true for ext3 as well. You may not see problems on every power loss,
but eventually you will.
The problems are often found after the fact, with a subsequent runtime or fsck
error, so the culprit may not be immediately obvious.
-Eric
> Regards,
> Dennis
More information about the devel
mailing list