Messages in this thread | | | Date | Wed, 06 May 2015 19:50:48 +0300 | From | Boaz Harrosh <> | Subject | Re: [PATCH v2] Support for write stream IDs |
| |
On 05/06/2015 01:09 AM, Martin K. Petersen wrote: >>>>>> "Jens" == Jens Axboe <axboe@fb.com> writes: <> > > The only sensible solution is for the kernel to manage the stream > IDs. And for them to be plentiful. The storage device is free to ignore > them, do LRU or whatever it pleases to manage them if it has an internal > limit on number of open streams, etc. >
Sometimes you do not have control over the "storage device" firmware and/or it is already too late. But in such a case the LLD of the device can do the state management (open/close) and translation (LRU). If there are a lot of broken devices with the same small size that need an LRU and/or state, bunch of LLDs can reuse a common library.
But hey yes I'm with Martin here. It sounds like a filesystem thing and not an application thing.
From the application side we already have the O_TMP hint and other fadvise hits, but it is more the filesystem policy of what to do with this.
Also current proposed solution for application is kind of a layering violation. I set an Id at the filesystem level API: Open a file, set an ID. But I acquire the ID from the block device under the FS. This will never map well. In fact it calls for only a very hard-coded hardware specific application that can use this.
Thanks Boaz
| |