Messages in this thread | | | Date | Sun, 13 Oct 2002 16:35:51 +0100 | From | Christoph Hellwig <> | Subject | Re: [Evms-devel] Re: Linux v2.5.42 |
| |
On Sun, Oct 13, 2002 at 11:16:24PM +0800, Michael Clark wrote: > On 10/13/02 21:49, Christoph Hellwig wrote: > > On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote: > > > >>Exactly. I think Christoph is comparing it to the original md > >>architecture thich was more of an evolutionary design on the existing > >>block layer > > > > > > No, I do not. MD is in _no_ ways a volume managment framwork but just > > a few drivers that share common code. That's somethig entirely different. > > So why then the requirement that internal remapping layers be > implemented as block devices?
I don't care how a single remapping layers is implemented. I want the common Voulme managment API work on public nodes.
> Neither is implementing an internal logical remapping layer as a > block device just so you can do an ioctl directly to it.
Not without hacks.
> I think the point is really explaining why they _should_ be accessed. > If there is some valid reason other than having something you > can do an ioctl on.
Because that
a) removes hacks like the EVMS pass-though b) allows userspace to easily access it through read/write
> > > argumentation tell me why you haven't submitted a patch to Linus > > yet to disallow direct access to block devices that are in use > > by a filesystem. > > I think the issue here is an md block device in use by another md block > device. Possbily becuase md's design precludes this (a design artifact) > (ie. md tools need access to the intermediary devices - users don't).
I'm not talksing about MD here. Why do you want to disallow people using a device just it has another layer above it. E.g. write a change to the ondisk structures (setting a flag, etcc..) is most logically expressed by simple, O_DIRECT write to the actual device.
> Yes, but the block device encapsulation here removes the need for plugins > to be implemented as block devices ie. removing complexity elsewhere. > I must admit to not being an expert on the block layer - but wouldn't > your suggesed approach mean intermediary layers would each have a > request queue
It _coukd_ have a request queue, yes.
> and other unneeded stuff - if so, is this desirable?
What unneeded stuff? block device state contains no state relevant to userspace access.
> > This argument is NIL if the infrastructure is part of exactly that > > evolving block layer. You might have noticed that kernel code > > compatility to other releases is not really a criteria for the > > linux kernel development, btw.. > > I agree, maybe this would be worth doing for 2.7/2.8.
Yes.
> In the meatime > do you think this would be feasible? - you are basically suggesting > a complete rewrite
Exactly.
> (or do you think you can do the rewrite to IBM's > satisfaction before the freeze ie. in the eternal linux kernel way, > you want it you write it ;). Me, i'm happy with the current approach > - but of course, i'm only a user ;).
_I_ don't want to get EVMS in, sorry. I _do_ want a proper volume managment framework, but I can live with it not beeing in before 2.8.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |