Re: fs-independent quotas

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Oct 20, 2011 at 09:41:25PM +0200, Manuel Bouyer wrote:
 > > The lfs/ufs split would have been committed ages ago if the quota
 > > system hadn't gotten in the way. This is why, last spring, when yo
 > > were designing quota2, I was asking you to fix things above the FS to
 > > be FS-independent. But you didn't; instead it got worse. I tried at
 > > the time to explain the situation and the premises, and why the quota
 > > system should be FS-independent at and above the VFS level, but I got
 > > ignored and then sucked away by real life.
 > 
 > Well, I don't remember the details of that time but what I retained
 > is that you didn't like xml.

That was so not the point. But whatever, like I just said, I give up.

 > Now you're saying "I move lfs out of ufs and I can't use quota1 for lfs".
 > Yes, of course as quota1 is tightly coupled to ufs, and my project was
 > not to make quota1 filesystem-independant - it was to add a new
 > on-disk quota for ffs with some better properties. You can't blame
 > me for not making quota1 (or even quota2) reusable outside of ufs when 
 > my goal was to get a new on-disk format for ffs. That's just not the
 > same work.

No. That's not what I'm saying now or then. What I was (and am) asking
for was (and is) to make it reasonably possible to use a quota format
*other* than the existing ufs-only one(s).

 > Nothing outside of sys/ufs/ uses ffs-quota2 on-disk structures, they use
 > ufs_quota_entry from common/include/quota/quotaprop.h (you'll claim it's
 > usf-specific but it's not: it's the format you described. The ufs here
 > means "ufs-like semantic"). 

That was an amazingly poor choice of names.

 > > No, because I had something like the old quotactl(2) in mind - an
 > > ordinary call passing a filesystem identifier, a command code, and an
 > > argument.
 > 
 > This caused issues for puffs. This is another place where plist is a win.

As I recall it was switching to plists that caused issues. But,
whatever.

 > And no there's no compat versionning needed here.

This is not true. People have claimed this before (that proplib makes
all compat versioning issues go away) and it wasn't true then and it
still isn't true now. But, as far as I'm concerned, it's now someone
else's problem.

 > I dissagree. a columnar file delimited by whitespace may be fine
 > for shell scripts (if you don't have fields that can be empty or be a
 > single whitespace, because then you have problems), but it's not for e.g.
 > perl or python.

Um? In both those languages it's a single call to split, just like in
awk.

-- 
David A. Holland
dholland%netbsd.org@localhost