Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1720380
| From | Dan Williams <dan.j.williams@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED |
| Date | 2017-08-25 21:50 +0200 |
| Message-ID | <uisM9-8cd-13@gated-at.bofh.it> (permalink) |
| References | <uhNIZ-78j-1@gated-at.bofh.it> <uhNJ0-78j-23@gated-at.bofh.it> <ui31n-pa-3@gated-at.bofh.it> <uifYB-nL-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Aug 24, 2017 at 11:00 PM, Dan Williams <dan.j.williams@intel.com> wrote: > On Thu, Aug 24, 2017 at 9:13 AM, Christoph Hellwig <hch@lst.de> wrote: >> I'm still very unhappy about the get/set flag state. What is the >> reason you can't use/extend leases? (take a look at the fcntl >> man page and look for Leases). A variant of the concept is what >> the pNFS block server uses. > > So I think leases could potentially be extended to replace the inode > flag. A MAP_DIRECT operation would take out a lease that is broken by > break_layouts(). However, like the pNFS case the lease break would > need to held off while any DMA might be in-flight. We can use an > elevated page count as that indication as ZONE_DEVICE pages only ever > have an elevated page count in response to get_user_pages(). > > However, I think the only practical difference is turning an immediate > ETXTBSY response that S_IOMAP_SEALED provides into an indefinite > blocking wait for break_layouts() to complete. Can pNFS run > break_layouts() in bounded time? > > As far I can see a lease and S_IOMAP_SEALED have the same DMA > cancelling problem, so a lease is not better in that regard. Absent an > overlaying protocol like pNFS, I think S_IOMAP_SEALED is cleaner > because it fails incompatible operations outright rather than stalls > them in break_layouts(). Were their other benefits to a lease over an > inode flag that you had in mind for this case where the protocol is > userspace defined? Maybe I'm thinking too small on the ways a lease > might be extended. At a minimum I can at least use a new lease type as an indication of when to bail out an block-map operation with ETXTBSY, and reuse the lease security model. That way we at least start to converge the in-kernel lease machinery for pinning blocks with this userspace mechanism.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v6 0/5] MAP_DIRECT and block-map-atomic files Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
[PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Christoph Hellwig <hch@lst.de> - 2017-08-24 18:20 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Christoph Hellwig <hch@lst.de> - 2017-08-24 18:40 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Dan Williams <dan.j.williams@intel.com> - 2017-08-24 22:30 +0200
Re: [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges Dan Williams <dan.j.williams@intel.com> - 2017-08-24 18:40 +0200
[PATCH v6 5/5] fs, fcntl: add F_MAP_DIRECT Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
[PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Jan Kara <jack@suse.cz> - 2017-08-24 15:10 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Christoph Hellwig <hch@infradead.org> - 2017-08-24 19:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-24 19:40 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Christoph Hellwig <hch@infradead.org> - 2017-08-25 15:10 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-25 18:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Christoph Hellwig <hch@infradead.org> - 2017-08-25 18:10 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-25 18:20 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Helge Deller <deller@gmx.de> - 2017-08-25 18:30 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-08-25 19:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-25 22:30 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Helge Deller <deller@gmx.de> - 2017-08-26 09:50 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-26 17:20 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Helge Deller <deller@gmx.de> - 2017-08-26 22:00 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Dan Williams <dan.j.williams@intel.com> - 2017-08-27 00:50 +0200
Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-27 02:00 +0200
[PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Dan Williams <dan.j.williams@intel.com> - 2017-08-24 02:00 +0200
Re: [PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Christoph Hellwig <hch@lst.de> - 2017-08-24 18:20 +0200
Re: [PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Dan Williams <dan.j.williams@intel.com> - 2017-08-25 08:10 +0200
Re: [PATCH v6 2/5] fs, xfs: introduce S_IOMAP_SEALED Dan Williams <dan.j.williams@intel.com> - 2017-08-25 21:50 +0200
Re: [PATCH v6 0/5] MAP_DIRECT and block-map-atomic files Christoph Hellwig <hch@lst.de> - 2017-08-24 18:10 +0200
Re: [PATCH v6 0/5] MAP_DIRECT and block-map-atomic files Dan Williams <dan.j.williams@intel.com> - 2017-08-24 18:30 +0200
Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations' Christoph Hellwig <hch@infradead.org> - 2017-08-24 19:00 +0200
Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations' Dan Williams <dan.j.williams@intel.com> - 2017-08-24 19:50 +0200
csiph-web