> "Jens" == Jens Axboe writes:
Jens,
Jens> There are actual technical challenges on the device side that
Jens> sometimes interferes. [...]
Right now we use the same protocol to speak to USB keys and million
dollar storage arrays. That's because the protocol was designed to be
abstract and
Jens == Jens Axboe ax...@fb.com writes:
Jens,
Jens There are actual technical challenges on the device side that
Jens sometimes interferes. [...]
Right now we use the same protocol to speak to USB keys and million
dollar storage arrays. That's because the protocol was designed to be
abstract
On 05/07/2015 01:19 PM, Martin K. Petersen wrote:
"Jens" == Jens Axboe writes:
Jens> This wont solve the problem of devices having too few streams. But
Jens> it'll work regardless, we'll just have to push them separately to
Jens> do that. It's not an easy problem for them either, resource
On 05/07/2015 01:19 PM, Martin K. Petersen wrote:
Jens == Jens Axboe ax...@fb.com writes:
Jens This wont solve the problem of devices having too few streams. But
Jens it'll work regardless, we'll just have to push them separately to
Jens do that. It's not an easy problem for them either,
> "Jens" == Jens Axboe writes:
Jens> This wont solve the problem of devices having too few streams. But
Jens> it'll work regardless, we'll just have to push them separately to
Jens> do that. It's not an easy problem for them either, resource
Jens> constraints on the device side could exclude
Jens == Jens Axboe ax...@fb.com writes:
Jens This wont solve the problem of devices having too few streams. But
Jens it'll work regardless, we'll just have to push them separately to
Jens do that. It's not an easy problem for them either, resource
Jens constraints on the device side could
On 05/06/2015 08:26 AM, Peter Zijlstra wrote:
On Tue, May 05, 2015 at 06:09:18PM -0400, Martin K. Petersen wrote:
"Jens" == Jens Axboe writes:
Jens> I'm not trying to make a shortcut. I deliberately do not want to
Jens> make ID generation/assignment part of the kernel. There's no
Jens>
On 05/05/2015 04:09 PM, Martin K. Petersen wrote:
"Jens" == Jens Axboe writes:
Jens> I'm not trying to make a shortcut. I deliberately do not want to
Jens> make ID generation/assignment part of the kernel. There's no
Jens> reason that can't exist outside of the kernel, in a libstreamid or
On 05/06/2015 01:09 AM, Martin K. Petersen wrote:
>> "Jens" == Jens Axboe 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
On Tue, May 05, 2015 at 06:09:18PM -0400, Martin K. Petersen wrote:
> > "Jens" == Jens Axboe writes:
>
> Jens> I'm not trying to make a shortcut. I deliberately do not want to
> Jens> make ID generation/assignment part of the kernel. There's no
> Jens> reason that can't exist outside of the
On Tue, May 05, 2015 at 06:09:18PM -0400, Martin K. Petersen wrote:
Jens == Jens Axboe ax...@fb.com writes:
Jens I'm not trying to make a shortcut. I deliberately do not want to
Jens make ID generation/assignment part of the kernel. There's no
Jens reason that can't exist outside of the
On 05/06/2015 01:09 AM, Martin K. Petersen wrote:
Jens == Jens Axboe ax...@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
On 05/06/2015 08:26 AM, Peter Zijlstra wrote:
On Tue, May 05, 2015 at 06:09:18PM -0400, Martin K. Petersen wrote:
Jens == Jens Axboe ax...@fb.com writes:
Jens I'm not trying to make a shortcut. I deliberately do not want to
Jens make ID generation/assignment part of the kernel. There's no
On 05/05/2015 04:09 PM, Martin K. Petersen wrote:
Jens == Jens Axboe ax...@fb.com writes:
Jens I'm not trying to make a shortcut. I deliberately do not want to
Jens make ID generation/assignment part of the kernel. There's no
Jens reason that can't exist outside of the kernel, in a libstreamid
> "Jens" == Jens Axboe writes:
Jens> I'm not trying to make a shortcut. I deliberately do not want to
Jens> make ID generation/assignment part of the kernel. There's no
Jens> reason that can't exist outside of the kernel, in a libstreamid or
Jens> similar.
That just perpetuates the broken
On 05/05/2015 03:39 PM, Martin K. Petersen wrote:
"Jens" == Jens Axboe writes:
Jens> The kernel patches deal only with ensuring that the stream
Jens> information gets passed down. If the device requires explicit
Jens> stream open/close actions, then that needs to be handled on the
Jens> side.
> "Jens" == Jens Axboe writes:
Jens> The kernel patches deal only with ensuring that the stream
Jens> information gets passed down. If the device requires explicit
Jens> stream open/close actions, then that needs to be handled on the
Jens> side.
Well, I'm deeply concerned about that "on the
On 05/05/2015 02:51 PM, Jeff Moyer wrote:
Jens Axboe writes:
Hi,
Changes since the last posting:
- Added a specific per-file fadvise setting. POSIX_FADV_STREAMID sets
the inode and file stream ID, POSIX_FADV_STREAMID_FILE sets just the
file stream ID.
- Addressed review comments.
Jens Axboe writes:
> Hi,
>
> Changes since the last posting:
>
> - Added a specific per-file fadvise setting. POSIX_FADV_STREAMID sets
> the inode and file stream ID, POSIX_FADV_STREAMID_FILE sets just the
> file stream ID.
>
> - Addressed review comments.
>
> I've since run some testing
On Tue, May 05, 2015 at 02:31:34PM -0600, Jens Axboe wrote:
> There is a user, we are using it. And there's no data structure bloating,
> both the file and inode additions are filling existing holes.
FYI, they do increase the size on any 32-bit architecture, which is
where it hurts most.
--
To
On Tue, May 05, 2015 at 02:31:34PM -0600, Jens Axboe wrote:
> Even outside of that, there are use cases for caching that need not have
> hardware assist.
Could, would. But in the meantime you'd adding dead wood kernel code,
and even worse user interfaces.
> >Merging infrastructure without any
On 05/05/2015 02:20 PM, Christoph Hellwig wrote:
On Tue, May 05, 2015 at 02:12:01PM -0600, Jens Axboe wrote:
We can't merge the NVMe bits until the proposal is included/finalized. But
this is a problem. I don't want to add this to the Facebook kernel until we
know the API is stable, while I
On Tue, May 05, 2015 at 02:12:01PM -0600, Jens Axboe wrote:
> We can't merge the NVMe bits until the proposal is included/finalized. But
> this is a problem. I don't want to add this to the Facebook kernel until we
> know the API is stable, while I have no problem adding experimental NVMe
>
On 05/05/2015 02:07 PM, Christoph Hellwig wrote:
On Tue, May 05, 2015 at 02:02:54PM -0600, Jens Axboe wrote:
Unless there are any grave concerns here, I'd like to merge this for
4.2.
Without a driver implementing the feature I don't see any reason to even
consider merging it.
We can't merge
On Tue, May 05, 2015 at 02:02:54PM -0600, Jens Axboe wrote:
> Unless there are any grave concerns here, I'd like to merge this for
> 4.2.
Without a driver implementing the feature I don't see any reason to even
consider merging it.
--
To unsubscribe from this list: send the line "unsubscribe
Hi,
Changes since the last posting:
- Added a specific per-file fadvise setting. POSIX_FADV_STREAMID sets
the inode and file stream ID, POSIX_FADV_STREAMID_FILE sets just the
file stream ID.
- Addressed review comments.
I've since run some testing with write streams. Test case was a
Jens == Jens Axboe ax...@fb.com writes:
Jens I'm not trying to make a shortcut. I deliberately do not want to
Jens make ID generation/assignment part of the kernel. There's no
Jens reason that can't exist outside of the kernel, in a libstreamid or
Jens similar.
That just perpetuates the broken
On Tue, May 05, 2015 at 02:12:01PM -0600, Jens Axboe wrote:
We can't merge the NVMe bits until the proposal is included/finalized. But
this is a problem. I don't want to add this to the Facebook kernel until we
know the API is stable, while I have no problem adding experimental NVMe
changes
Hi,
Changes since the last posting:
- Added a specific per-file fadvise setting. POSIX_FADV_STREAMID sets
the inode and file stream ID, POSIX_FADV_STREAMID_FILE sets just the
file stream ID.
- Addressed review comments.
I've since run some testing with write streams. Test case was a
On 05/05/2015 02:20 PM, Christoph Hellwig wrote:
On Tue, May 05, 2015 at 02:12:01PM -0600, Jens Axboe wrote:
We can't merge the NVMe bits until the proposal is included/finalized. But
this is a problem. I don't want to add this to the Facebook kernel until we
know the API is stable, while I
On Tue, May 05, 2015 at 02:31:34PM -0600, Jens Axboe wrote:
Even outside of that, there are use cases for caching that need not have
hardware assist.
Could, would. But in the meantime you'd adding dead wood kernel code,
and even worse user interfaces.
Merging infrastructure without any users
On Tue, May 05, 2015 at 02:02:54PM -0600, Jens Axboe wrote:
Unless there are any grave concerns here, I'd like to merge this for
4.2.
Without a driver implementing the feature I don't see any reason to even
consider merging it.
--
To unsubscribe from this list: send the line unsubscribe
On 05/05/2015 02:07 PM, Christoph Hellwig wrote:
On Tue, May 05, 2015 at 02:02:54PM -0600, Jens Axboe wrote:
Unless there are any grave concerns here, I'd like to merge this for
4.2.
Without a driver implementing the feature I don't see any reason to even
consider merging it.
We can't merge
Jens Axboe ax...@fb.com writes:
Hi,
Changes since the last posting:
- Added a specific per-file fadvise setting. POSIX_FADV_STREAMID sets
the inode and file stream ID, POSIX_FADV_STREAMID_FILE sets just the
file stream ID.
- Addressed review comments.
I've since run some testing
On Tue, May 05, 2015 at 02:31:34PM -0600, Jens Axboe wrote:
There is a user, we are using it. And there's no data structure bloating,
both the file and inode additions are filling existing holes.
FYI, they do increase the size on any 32-bit architecture, which is
where it hurts most.
--
To
On 05/05/2015 03:39 PM, Martin K. Petersen wrote:
Jens == Jens Axboe ax...@fb.com writes:
Jens The kernel patches deal only with ensuring that the stream
Jens information gets passed down. If the device requires explicit
Jens stream open/close actions, then that needs to be handled on the
Jens
On 05/05/2015 02:51 PM, Jeff Moyer wrote:
Jens Axboe ax...@fb.com writes:
Hi,
Changes since the last posting:
- Added a specific per-file fadvise setting. POSIX_FADV_STREAMID sets
the inode and file stream ID, POSIX_FADV_STREAMID_FILE sets just the
file stream ID.
- Addressed review
Jens == Jens Axboe ax...@fb.com writes:
Jens The kernel patches deal only with ensuring that the stream
Jens information gets passed down. If the device requires explicit
Jens stream open/close actions, then that needs to be handled on the
Jens side.
Well, I'm deeply concerned about that on the
Hi,
v2 of this posting. Changes since v1:
- Rebased on top of current master.
- Fix EINVAL -> -EINVAL typo.
- Cleanup up BIO_STREAM_OFFSET definition.
- Pack i_streamid and f_streamid better into struct file and struct
inode.
- Add a separate per-file hint, FADV_FILE_STREAMID. This only
Hi,
v2 of this posting. Changes since v1:
- Rebased on top of current master.
- Fix EINVAL - -EINVAL typo.
- Cleanup up BIO_STREAM_OFFSET definition.
- Pack i_streamid and f_streamid better into struct file and struct
inode.
- Add a separate per-file hint, FADV_FILE_STREAMID. This only
40 matches
Mail list logo
