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:
* 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.
* there is no easy way to tell if a particular stat-data is in v1 or v2
format in link.
But maybe we could:
* define nlink_t to be unsigned int (it is unsigned short now)
* 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?)
* 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?)
--
Ragnar Kjørstad
Big Storage
