> On Sun, Jan 07, 2007 at 03:36:14PM +0900, YAMAMOTO Takashi wrote:
> > > > i meant, the framework should be designed so that it can track
> > > > which parts of disks are used by who, rather than hardcoding your policy.
> > > 
> > > I won't comment on that, because that is a rather hypothetical
> > > statement... when it's finished, we'll get back to it. :)
> > 
> > how about something like the attached patch?
> > "query" part is not yet, but it shouldn't be too hard.
> 
> I think we've since agreed with you about making the framework track usage 
> rather than hardcoding policy (see the semantic change I proposed).
> 
> I'm not sure I like this change. It's a very good implementation of what 
> someone suggested we have in the form of byte range locking. However, I 
> don't see the advantage of byte range locking. I think we should just do 
> partition use verification and thats it.
> 
> I've heard two reasons for byte range locking. One was that folks have had 
> partitions move around while in use. I agree this is really bad, but I 
> think it's flat-out a bug! Open partitions SHOULD NOT MOVE. I don't care 
> what part of it you are using, it should stay put. :-) So I think the 
> direct fix is to prevent changing live partitions, not adding a different 
> checking method.
> 
> The other reason I've heard given for byte range locking is for something
> like writing boot blocks in the first 8k or 32k of a file system. I don't
> think that's a good reason though. That's the only access I can think of
> where you would want sub-partition ideas. However it's exactly a time when
> you NEED to know what you are doing, so requiring userland to know doesn't
> seem that bad a deal. Plus, we are discussing open checks that are
> performed at some secure level - after we have started booting multi-user.
> However I always thought of that as a time when we would NOT want to be
> updating the boot code. Put another way, if you are the kind of person who
> might want to update boot code after booting multi-user (like me, to be
> honest :-), chances are you don't care about these checks.  Likewise, if
> you care about not overwriting active partitions, chances are you don't 
> want to update boot code after startup.

i'm not suggesting to support sub-partitions etc at all.
byte range tracking merely happened to be the easiest way for me to track
usages of wedges and traditional partitions in a unified manner.

> So we're talking about a lot of complexity that I don't think will ever 
> get used. I say we leave it out and just go with partitions. Partitions 
> that don't move around.

i'm not sure what complexity you are talking about.
a range (two uint64_t) vs a partition number (int)?
if you use a partition number, how do you represent users of wedges?

or are you saying what elad's "sysdisk" does is enough?
it's flawed IMO, given that it lacks a way for drivers like raidframe
to propagate usage info to underlying disks.

YAMAMOTO Takashi