From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [RFC 01/16] NOVA: Documentation From: Steven Swanson In-Reply-To: <1501859388.2757.1.camel@wdc.com> Date: Sat, 5 Aug 2017 20:28:08 -0700 Cc: "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "swanson@eng.ucsd.edu" , "linux-fsdevel@vger.kernel.org" , "dan.j.williams@intel.com" Content-Transfer-Encoding: quoted-printable Message-Id: <873FD9AB-8E7B-495B-A74C-D2AAA4305432@gmail.com> References: <150174646416.104003.14042713459553361884.stgit@hn> <150174649708.104003.4595004262958377346.stgit@hn> <1501859388.2757.1.camel@wdc.com> To: Bart Van Assche Sender: linux-kernel-owner@vger.kernel.org List-ID: There is nothing impossible COW for mapped files, but it is not a good match= for the expected usage model for DAX. =20 The idea is that programs can mmap files and the build interesting data stru= ctures in them, just like they do in DRAM. This means lots of small updatEs= , and that would be very slow if each of them required a COW. The reason we use COW for normal accesses is to provide atomicity. Programs= will probably want doe form of atomicity for their mmaped data structures, b= ut part of the DAX bargain is that programmer are responsible for this rathe= r than the FS. -steve -- Composed on (and maybe dictated to) my phone. > On Aug 4, 2017, at 08:09, Bart Van Assche wrote: >=20 >> On Thu, 2017-08-03 at 00:48 -0700, Steven Swanson wrote: >> +### DAX Support >> + >> +Supporting DAX efficiently is a core feature of NOVA and one of the chal= lenges >> +in designing NOVA is reconciling DAX support which aims to avoid file sy= stem >> +intervention when file data changes, and other features that require suc= h >> +intervention. >> + >> +NOVA's philosophy with respect to DAX is that when a program uses DAX mm= ap to >> +to modify a file, the program must take full responsibility for that dat= a and >> +NOVA must ensure that the memory will behave as expected. At other time= s, the >> +file system provides protection. This approach has several implications= : >> + >> +1. Implementing `msync()` in user space works fine. >> + >> +2. While a file is mmap'd, it is not protected by NOVA's RAID-style pari= ty >> +mechanism, because protecting it would be too expensive. When the file i= s >> +unmapped and/or during file system recovery, protection is restored. >> + >> +3. The snapshot mechanism must be careful about the order in which in ad= ds >> +pages to the file's snapshot image. >=20 > Hello Steven, >=20 > Thank you for having shared this very interesting work. After having read t= he > NOVA paper and patch 01/16 I have a question for you. Does the above mean t= hat > COW is disabled for writable mmap-ed files? If so, what is the reason behi= nd > this? Is there a fundamental issue that does not allow to implement COW fo= r > writable mmap-ed files? Or have you perhaps tried to implement this and wa= s the > performance not sufficient? Please note that I'm neither a filesystem nor a= > persistent memory expert. >=20 > Thanks, >=20 > Bart.