Re: [PATCH] Add WRITE_ATOMIC_16 support

FUJITA Tomonori <[email protected]> Wed, 23 Sep 2015 12:16:16 +0900 (JST)
Newsgroups org.kernel.vger.stgt
Message-ID <20150923.121616.1568838937885768056.fujita.tomonori@lab.ntt.co.jp>
On Wed, 16 Sep 2015 12:49:14 -0700
ronnie sahlberg <[email protected]> wrote:

> On Tue, Sep 15, 2015 at 2:54 AM, FUJITA Tomonori
> <[email protected]> wrote:
>> On Wed,  9 Sep 2015 11:43:54 -0700
>> Ronnie Sahlberg <[email protected]> wrote:
>>
>>> Please find attached a patch that adds support for the new opcode
>>> WRITE_ATOMIC_16 to the bs_rdwr backend.
>>>
>>> I try to make it as atomic as possible by using mmap and mlock to ensure that
>>> both the write buffer and the file region we are writing to will be all
>>> present and locked down in memory before I just memcpy() the data.
>>> At that stage it is then assumed that the memcpy() will never fail short.
>>
>> But it's still possible that the data written to the underlying file
>> system in 'non-atomic' manner in the case of linux kernel crash or
>> such?
> 
> True.
> If there is a kernel panic between when we issue msync() and until the
> kernel has fully destaged all the data, the write will not be atomic
> and we will end up with a short write :-(
> 
> That should be rare-ish though so we should be able to live with it?
> If not, since the backing file is supposed to be a plain posix file,
> do you have any suggestions or pointers on how I can make the
> atomicity
> stronger, I have tried to think about it but since filesystems is not
> my strongest side I can not come up with anything better right now.

Btrfs doesn't guarantee this yet? EXT3's data=journal is still broken?