Hi
Ragnar Kjørstad wrote:
> On Mon, May 28, 2001 at 06:41:42AM +0400, Vladimir V. Saveliev wrote:
> > > * there is no easy way to tell if a particular stat-data is in v1 or v2
> > > format in link.
> >
> > Yes, there is. They have different length.
>
> But this information is not easily available where it's actually used,
> in mkdir and link. (you're talking about on-disk structure length,
> right?)
>
Yes.
But we can add something like i_sd_version in addition to i_version.
>
> > > * save stat-data version number in reiserfs-specific part of the inode.
> > > (e.g. in i_version - we discussed this once before, but for some
> > > reason it was not changed)
>
> Looking at it again, I see that i_version _is_ set, only it's always set
> to 1 for directories.
>
This i_vesion should be renamed to i_key_version. Because it says which keys do all
items (but stat data) of an object have.
Directory items (even if a directory has new stat data) have keys of old format.
>
> > > Maybe instead of i_version the inode should have a pointer to a
> > > version-dependent struct, that can include e.g. MAX_LINKS and others? I
> > > suppose if other stat-data versions are invented later on, there will be
> > > many things that differ (e.g. a stat-data version without timestamps may
> > > make sense?)
> >
> > filesystem specific union of struct inode is still almost not used by reiserfs, so,
> > we can store there a lot of things like real number of links, etc
>
> real number of links should be stored in the generic part of the inode,
> so stat and friends will find it.
>
Yes, when inode's i_nlink will get long enough.
>
> But what I suggested was a datastructure that didn't only depend on
> filesystem, but on inode items version for this particular inode - it
> can hold constants and potentially pointers to functions that differ
> from item-version to item-version.
>
Would something like
union reisersf_inode_info {
struct stat_data_v1 v1_data;
struct stat_data_v1 v2_data;
struct stat_data_v1 v3_data;
....
};
work? I just think that we should avoid need to care about allocation/freeing of that
per inode dtastructure.
Thanks,
vs
