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

Reply via email to