On Mon, 2009-01-12 at 14:23 -0500, Jeff Garzik wrote:It's an indicator of one. If you buy my premise that OSD cannot beIf having a compelling user case was a prereq for kernel inclusion, well over half the code would be gone.
relevant without compelling user cases, then the lack of a user API can
be viewed as a symptom of this.
I'm not holding this against inclusion ... I'm saying it's a symptom of
the generic relevance to user issues problem that OSD has.
I think your choice of using a character device will turn out to be aIt is fantasy to think we will be migrating ext4 to OSD. That fantasy is not a compelling reason to block OSD development.
design mistake because the migration path of existing filesystems is
bound to be a block device with extra features (which they may or may
not make use of) but only if there's a way to make ODS relevant to
users.
OK, so your quote managed to miss this bit:
"Right, so I'm reasonably happy to accept libosd for what it is: an
enabler for a few specialised applications. "
I can't see how that can be construed as "blocking OSD development".
The word "accept" is conventionally used in Linux parlance to mean "will
send upstream".
To sum,
* exofs needs a userspace library, around which the standard filesystem tools will be built, most notably mkfs, dump, restore, fsck
* talk of migrating existing filesystems is wildly premature (and a bit of a silly argument, since you are also arguing that OSD lacks compelling use cases)
So criticising lacking compelling use cases while at the same time
suggesting how to find them is wrong?
Actually, If the only use case OSD can bring to the table is requiring
new filesystems, then there's nothing of general user relevance for it
on the horizon ... anywhere. There's never going to be a compelling
reason to move the consumer OSDs in the various development labs to
production because nothing would be able to use them on a mass scale.
If we could derive a benefit from OSD in existing filesystems, then they
do have user relevance, and Seagate and the others might just consider
releasing the devices.
Note that "providing benefit to" does not equate to "rewriting the
filesystem for" ... and it shouldn't; the benefit really should be
incremental. And that's the crux of my criticism. While OSD are
separate things that we have to rewrite whole filesystems for, they're
never going to set the world on fire. If they could be used with only
incremental effort, they might. The bridge for the incremental effort
will come from a properly designed kernel API.
* an in-kernel OSD-based filesystem needs some sort of generic in-kernel libosd API, so that multiple OSD filesystems do not reinvent the wheel each time.
* OSD was bound to be annoying, because it forces the kernel filesystem to either (a) talk SCSI or (b) use messages that can be converted to SCSI OSD commands, like existing drivers convert the block layer's READ and WRITE to device-specific commands.
OK, so what you're arguing is that unlike block devices where we can
produce a useful generic abstraction that is protocol agnostic, for OSD
we can't? As I've said before, I think this might be true, but fear it
dooms OSD to being too difficult to use.
* Trying to force OSD to export a block device is pushing a square peg through a round hole. Thus, the best (and only) alternative is character device. What you really want is a Third Way(tm): a mmap'able message device, since you really want to export an API to userspace.
only allowing a character tap raises the effort bar on getting other
filesystems to use it, because they're all block based ...