Subject: Re: Y2038, was as long as we're hitting FFS...
To: Bill Studenmund <email@example.com>
From: Ted Lemon <firstname.lastname@example.org>
Date: 03/26/1999 09:45:06
> Also, what do you do if the agregate of stored info is more than say the
> 128 bytes we're proposing growing the inode? Answering this question is
> a big part of the reason why I think the general solution is hard. :-)
The kernel returns ENOSPC. Same thing that happens when you fill a
disk - just sooner. In the sense that you mean general, there are no
> Also, userland would need to have a library to grovel this. I'd assume
> we'd then want to just turn the full inode growth over to this storage.
> For one thing, the ACL pointer would go in here, and dump would need to
> know how to find it. Plus we have userland code which needs to look at the
> on-disk fs image.
I think the ACL pointer is actually a poor example, and you debunked
it in a previous message. If FFS is doing the ACL, it might as well
be a first-class object.
> If you're going to do this, I'd vote for 16-bit magic and 16-bit length.
> Also, this design would need to keep everything in a fixed order so that
> the parser can figure out what's going on.
Dude, the field is only 96 bytes - why do you need to store a 16-bit
length? Why does it need to keep everything in a fixed order?
> No, not necessarily. All our layer cares about is if its calls to set &
> store data work on the fs it's mounted over. If you (or someone else)
> come(s) along and add a broader API, which can support all sorts of stuff,
> including the implicitly-96-byte ops, then our layer will be happy. :-)
I think you should simply use an API in which you explicitly provide
the length, even though you'll always say 96.