| To: | Boaz Harrosh <boaz@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: xfs: untangle the direct I/O and DAX path, fix DAX locking |
| From: | Christoph Hellwig <hch@xxxxxx> |
| Date: | Tue, 28 Jun 2016 15:39:28 +0200 |
| Cc: | Christoph Hellwig <hch@xxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-nvdimm@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <57727B27.7060104@xxxxxxxxxxxxx> |
| References: | <1466609236-23801-1-git-send-email-hch@xxxxxx> <20160623232446.GA12670@dastard> <20160624072612.GA22205@xxxxxx> <20160624230045.GG12670@dastard> <20160628131059.GA30475@xxxxxx> <57727B27.7060104@xxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.17 (2007-11-01) |
On Tue, Jun 28, 2016 at 04:27:03PM +0300, Boaz Harrosh wrote: > > Right. And an existing application can get DAX turned on under its > > back, and will now suddently get different synchronization behavior. > > That is if it's writes happen to be aligned to the fs block size. > > > > Is there an actual application that does that? or is this purely > theoretical right now? Lots of them. The typical case is multithreaded (or preforked like old apache) daemons that use O_APPEND to write to a common log file. Then again those log records will usually not be 4k aligned, so they'd still accidentally get the exclusive locking even without this patch. But beware the case where a log record actually matches the alignment.. > > > Thanks > Boaz ---end quoted text--- |
| Previous by Date: | Re: iomap infrastructure and multipage writes V5, Christoph Hellwig |
|---|---|
| Next by Date: | Re: xfs: untangle the direct I/O and DAX path, fix DAX locking, Boaz Harrosh |
| Previous by Thread: | Re: xfs: untangle the direct I/O and DAX path, fix DAX locking, Boaz Harrosh |
| Next by Thread: | Re: xfs: untangle the direct I/O and DAX path, fix DAX locking, Boaz Harrosh |
| Indexes: | [Date] [Thread] [Top] [All Lists] |