On Tue, Sep 15, 2015 at 2:54 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Wed, 9 Sep 2015 11:43:54 -0700 > Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> 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. regards ronnie sahlberg -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
