Benny Halevy wrote:
IMO the main advantage of moving block allocation down to the OSD target is more apparent with distributed file systems a-la pNFS over objects where paralleling that task is a key for scalable performance. The thing is that the target needs to implement its own mapping from object logical offsets into disk blocks and this is usually done using some kind of a (possibly trimmed down) local file system. Therefore the I/O performance of a single OSD is likely to be similar to a single file server's.
Well, modern SATA devices are already mini-filesystems internally, when you consider logical block remapping etc.
And the claim by drive research guys at the filesystem/storage summit was that OSD offered the potential to better optimize storage based on access/usage patterns.
(of course, whether or not reality bears out this guess is another question)
I can understand representing a single object as a block device (although I think that using a file for that should be good enough and easier) but why representing the whole OSD as a block device? The OSD holds partitions and objects each with attributes and OSD security related support. Hence representing that in a namespace using a filesystem seems straight forward.
I am actually considering writing a simple "osdblk" driver, that would represent a single object as a block device.
This would NOT replace exofs or other OSD filesystems, but it would be nice to have, and it will give me more experience with OSDs.
Jeff -- 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
