Re: [PATCH] cowlinks v2

From: jlnance
Date: Mon Apr 05 2004 - 06:11:56 EST


On Fri, Apr 02, 2004 at 11:39:34PM +0200, Pavel Machek wrote:

> > get_data_id() is one way to detect equivalent files. Another would be
> > a function files_equal(fd1, fd2) which returns a boolean.
>
> files_equal(...) would lead to quadratic number of calls, no?
>
> > get_data_id() has the advantage that it can report immediately whether
> > a file has _any_ cowlink peers, which is important for programs that
> > scan trees. Perhaps getxattr() would be reasonable interface, using a
> > named attribute "data-id".
>
> Yes, get_data_id() is extremely ugly name.

I think it is worth asking if we really want to give userspace a way of
doing this or not. It exposes fairly low level FS details to userspace,
and this will limit our ability to change the implementation of the FS
in the future (partially shared files?). Certainly there has been some
pain caused over the years because userspace can ask for the inode number,
and people have written file systems which do not use inodes. Then they
have to kluge around this and make something up. I would hate to see
us implement an interface that causes long term pain.

I also cant really think of anyone who would need this information. I have
seen diff and tar used as examples. Perhaps diff would run faster but that
seems like a very special case thing, and diff will certainly work w/o it.
Tar might also be faster creating archives if it had this information
available. However to make tar useful wrt cowlinks, it will need to be
able to create these links at extract time from tarfiles which were created
on non-cowlink filesystems, so I don't think there is a pressing need.

Of course, I am willing to believe that I am wrong. Hope you all have a
great day.

Thanks,

Jim

--
www.jeweltran.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/