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?