Re: [PATCH 0/11] Update version of write stream ID patchset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Jens" == Jens Axboe <axboe@xxxxxx> writes:

Jens> You are not missing anything, that's exactly how it is intended,
Jens> and that's how the interface is designed as well. If you want to
Jens> tie extra meaning to this for specific drivers or transports,
Jens> that's fine, and there's nothing that prevents that from
Jens> happening. As it stands, and as it is proposed, it's just a write
Jens> tag/stream ID that we can set on a file or inode, and have passed
Jens> to the driver. Nothing more, nothing less.

Yep. I'm fine with having the option of letting applications request an
ID from the kernel and being able to tag I/Os. But it is also imperative
that we are able to tag all remaining I/Os automatically. Hashing inode
and device/partition is fine, it does not have to be particularly
clever.

There are several types of non-flash storage in the pipeline that depend
on being able to identify blocks to disjoint LBA ranges as belonging to
the same "file". So as long as we don't go down the 10-channel flash
controller rat hole I'm perfectly happy...

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux