[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ1XODRNm6RyCNdQrUTKe2hOvECDVmxuzv6BUFY8eSX_MVSWSQ@mail.gmail.com>
Date: Wed, 5 Jun 2013 01:30:22 +0800
From: 宋柏翰 <solarispika@...il.com>
To: Eric Sandeen <sandeen@...hat.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Question on delalloc
Hi Eric,
I've found a mistake I'd made. I used to take for granted that
ext4 using ordered mode journal will have ext4_writepage do the
writing.
But with delalloc enabled, no matter what journal mode one uses, ext4
will use ext4_da_writepages do handle those delayed buffer heads'
writing.
Thanks for your advice, I know what you meant:) Though what I tried to
said is that delalloc'd data will stop kjournald from writing them
back when it would like to do so, therefore those delalloc'd data will
stay in memory more longer than those non-delalloc'd ones. As
described in http://lwn.net/Articles/322823/. Sorry for my unclear
statement.
Sung Po-Han
2013/6/4 Eric Sandeen <sandeen@...hat.com>:
> On 6/3/13 2:00 PM, 宋柏翰 wrote:
>> Hi everybody,
>>
>> I am new to ext4 and doing research on Android with ext4 as file
>> system. These days, I have a question on ext4's delayed allocation
>> against ext4_sync_file.
>> I have learned that delalloc won't guarantee file data's integrity on
>> power failure, since those delayed allocated buffer heads won't be
>> handled by jbd2.
>
> I just want to address your first assertion regarding delalloc:
>
>> In order to protect data, user programs need to fsync
>> those files to be secured.
>
> This is true with or without delayed allocation.
>
> With delayed allocation, the blocks are chosen a the time of the IO.
> Without delayed allocation, the blocks are chosen at the write syscall time.
>
> But in both cases, data is only in memory after the write(), and is not
> guaranteed to be on disk until an fsync or similar data integrity syscall.
>
> http://lwn.net/Articles/457667/
>
> -Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists