Finding hardlinks
Hi I've came across this problem: how can a userspace program (such as for example "cp -a") tell that two files form a hardlink? Comparing inode number will break on filesystems that can have more than 2^32 files (NFS3, OCFS, SpadFS; kernel developers already implemented iget5_locked for the case of colliding inode numbers). Other possibilities: --- compare not only ino, but all stat entries and make sure that i_nlink > 1? --- is not 100% reliable either, only lowers failure probability --- create a hardlink and watch if i_nlink is increased on both files? --- doesn't work on read-only filesystems --- compare file content? --- "cp -a" won't then corrupt data at least, but will create hardlinks where they shouldn't be. Is there some reliable way how should "cp -a" command determine that? Finding in kernel whether two dentries point to the same inode is trivial but I am not sure how to let userspace know ... am I missing something? Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding hardlinks
> I've came across this problem: how can a userspace program (such as for > example "cp -a") tell that two files form a hardlink? Comparing inode > number will break on filesystems that can have more than 2^32 files (NFS3, > OCFS, SpadFS; kernel developers already implemented iget5_locked for the > case of colliding inode numbers). Other possibilities: > > --- compare not only ino, but all stat entries and make sure that > i_nlink > 1? > --- is not 100% reliable either, only lowers failure probability > --- create a hardlink and watch if i_nlink is increased on both files? > --- doesn't work on read-only filesystems > --- compare file content? > --- "cp -a" won't then corrupt data at least, but will create > hardlinks where they shouldn't be. > > Is there some reliable way how should "cp -a" command determine that? > Finding in kernel whether two dentries point to the same inode is trivial > but I am not sure how to let userspace know ... am I missing something? The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend the kstat.ino field to 64bit and fix those filesystems to fill in kstat correctly. SUSv3 requires st_ino/st_dev to be unique within a system so the application shouldn't need to bend over backwards. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
inode i_blksize problem
Hi,
First of all sorry for my poor english.
I am trying to compile a module for kernel 2.6.18-1 that uses the 'inode
struct' but the compiler tell me inode struct hasn't a member called
"i_blksize". I don't have that problem in kernel 2.6.16. What happend
with i_blksize?
The funcion is like:
static inline foo (inode_t d, inode_t s)
{
.
d->i_blksize = s->i_blksize;
...
}
Thanks in advance.
Regards,
Sergio Paracuellos
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: inode i_blksize problem
On Wed, Dec 20, 2006 at 01:26:56PM +0100, Sergio Paracuellos wrote: > I am trying to compile a module for kernel 2.6.18-1 that uses the 'inode > struct' but the compiler tell me inode struct hasn't a member called > "i_blksize". I don't have that problem in kernel 2.6.16. What happend > with i_blksize? git-log reveals: commit ba52de123d454b57369f291348266d86f4b35070 Author: Theodore Ts'o <[EMAIL PROTECTED]> Date: Wed Sep 27 01:50:49 2006 -0700 [PATCH] inode-diet: Eliminate i_blksize from the inode structure This eliminates the i_blksize field from struct inode. Filesystems that wan t to provide a per-inode st_blksize can do so by providing their own getattr routine instead of using the generic_fillattr() function. Note that some filesystems were providing pretty much random (and incorrect) values for i_blksize. [EMAIL PROTECTED]: cleanup] [EMAIL PROTECTED]: generic_fillattr() fix] Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> So, it's gone. I'd just delete that line from your sources if I were you. By the way, what kind of module is this? Whatever it's doing looks pretty dodgy to me. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding hardlinks
I've came across this problem: how can a userspace program (such as for example "cp -a") tell that two files form a hardlink? Comparing inode number will break on filesystems that can have more than 2^32 files (NFS3, OCFS, SpadFS; kernel developers already implemented iget5_locked for the case of colliding inode numbers). Other possibilities: --- compare not only ino, but all stat entries and make sure that i_nlink > 1? --- is not 100% reliable either, only lowers failure probability --- create a hardlink and watch if i_nlink is increased on both files? --- doesn't work on read-only filesystems --- compare file content? --- "cp -a" won't then corrupt data at least, but will create hardlinks where they shouldn't be. Is there some reliable way how should "cp -a" command determine that? Finding in kernel whether two dentries point to the same inode is trivial but I am not sure how to let userspace know ... am I missing something? The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend the kstat.ino field to 64bit and fix those filesystems to fill in kstat correctly. There is 32-bit __st_ino and 64-bit st_ino --- what is their purpose? Some old compatibility code? SUSv3 requires st_ino/st_dev to be unique within a system so the application shouldn't need to bend over backwards. I see but kernel needs to be fixed for that. Would patches for changing kstat be accepted? Mikulas Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding hardlinks
> >> I've came across this problem: how can a userspace program (such as for > >> example "cp -a") tell that two files form a hardlink? Comparing inode > >> number will break on filesystems that can have more than 2^32 files (NFS3, > >> OCFS, SpadFS; kernel developers already implemented iget5_locked for the > >> case of colliding inode numbers). Other possibilities: > >> > >> --- compare not only ino, but all stat entries and make sure that > >>i_nlink > 1? > >>--- is not 100% reliable either, only lowers failure probability > >> --- create a hardlink and watch if i_nlink is increased on both files? > >>--- doesn't work on read-only filesystems > >> --- compare file content? > >>--- "cp -a" won't then corrupt data at least, but will create > >>hardlinks where they shouldn't be. > >> > >> Is there some reliable way how should "cp -a" command determine that? > >> Finding in kernel whether two dentries point to the same inode is trivial > >> but I am not sure how to let userspace know ... am I missing something? > > > > The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend > > the kstat.ino field to 64bit and fix those filesystems to fill in > > kstat correctly. > > There is 32-bit __st_ino and 64-bit st_ino --- what is their purpose? Some > old compatibility code? Yes. > > SUSv3 requires st_ino/st_dev to be unique within a system so the > > application shouldn't need to bend over backwards. > > I see but kernel needs to be fixed for that. Would patches for changing > kstat be accepted? I don't see any problems with changing struct kstat. There would be reservations against changing inode.i_ino though. So filesystems that have 64bit inodes will need a specialized getattr() method instead of generic_fillattr(). Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding hardlinks
On Wed, 20 Dec 2006, Al Viro wrote: On Wed, Dec 20, 2006 at 05:50:11PM +0100, Miklos Szeredi wrote: I don't see any problems with changing struct kstat. There would be reservations against changing inode.i_ino though. So filesystems that have 64bit inodes will need a specialized getattr() method instead of generic_fillattr(). And they are already free to do so. And no, struct kstat doesn't need to be changed - it has u64 ino already. I see, I should have checked recent kernel. Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding hardlinks
On Wed, Dec 20, 2006 at 05:50:11PM +0100, Miklos Szeredi wrote: > I don't see any problems with changing struct kstat. There would be > reservations against changing inode.i_ino though. > > So filesystems that have 64bit inodes will need a specialized > getattr() method instead of generic_fillattr(). And they are already free to do so. And no, struct kstat doesn't need to be changed - it has u64 ino already. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
