Hi
Ragnar Kjørstad wrote:
> On Sun, May 27, 2001 at 11:47:51PM +0400, Vladimir V. Saveliev wrote:
> > > > On a filesystem of 3.6 format you can have files longer than 2 gb and have
> > > > more that 64k links to a file.
> > > If you're refering to my patch, it doesn't allow more than 64k links,
> > > only more than 64k subdirectories. (but the format has room for 64k
> > > links)
> >
> > Oh, yes, we should have allowed that (more than 64535 links) for any files.
>
> If I remember correctly, this is not trivial, because:
>
It is doable, but afaics now it looks almost useless as far as st_nlink is 16 bit
even in stat64.
>
> * we must keep the correct link-count for regular files, or we may end
> up with a file without names without knowing it. (and we would
> leak disk space, as it would not get deleted)
>
> * we can't allow > 64k links to file if that particular file has stat-
> data in v1 format.
>
Yes, I meant v2 file only.
>
> * 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 maybe we could:
>
> * define nlink_t to be unsigned int (it is unsigned short now)
>
libc also will have to change, and that will probably make problems for existing
programs.
>
> * fix inode2sd, so it uses cpu_to_le32 instead of cpu_to_le16 for
> i_nlink. (I suppose this is just a typo, and should be fixed anyway?)
>
Yes.
>
> * 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)
>
> * change cp_old_stat() and cp_new_stat() to put magic number in nlink
> if inode->i_nlink > 2^32. 1?
>
> I suppose if we do this, we can remove the stuff I wrote to allow > 64k
> subdirectories. BUT, if we remove it, then users that actually have >
> 64k subdirectories will get warning "reiserfs_rmdir: empty directory has
> nlink != 2 (%d)" when they remove it.
>
> We could leave the "if nlink==1" test in there, but just remove the if
> nlink > REISERFS_MAX_LINKS test.
>
> We also need to put the tests for "too many links" back in mkdir - and
> this test needs to check the version-number for the stat-data.
>
> 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
Thanks,
vs
