I didn't hardlink directories, I just patched stat, lstat and fstat to
always return st_ino == 0 --- and I've seen those failures. These failures
are going to happen on non-POSIX filesystems in real world too, very
rarely.
I don't want to spoil your day but testing with st_ino==0 is a bad
On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote:
I didn't hardlink directories, I just patched stat, lstat and fstat to
always return st_ino == 0 --- and I've seen those failures. These
failures
are going to happen on non-POSIX filesystems in real world too, very
rarely.
I
On any decent filesystem st_ino should uniquely identify an object and
reliably provide hardlink information. The UNIX world has relied upon
this
for decades. A filesystem with st_ino collisions without being hardlinked
(or the other way around) needs a fix.
But for at least the last of those
On Wed, Jan 03, 2007 at 01:09:41PM -0800, Bryan Henderson wrote:
On any decent filesystem st_ino should uniquely identify an object and
reliably provide hardlink information. The UNIX world has relied upon
this
for decades. A filesystem with st_ino collisions without being hardlinked
(or the
Hi!
Sure it is. Numerous popular POSIX filesystems do that. There is a lot of
inode number space in 64 bit (of course it is a matter of time for it to
jump to 128 bit and more)
If the filesystem was designed by someone not from Unix world (FAT, SMB,
...), then not. And users still want to
On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
On Wed, Jan 03, 2007 at 01:09:41PM -0800, Bryan Henderson wrote:
On any decent filesystem st_ino should uniquely identify an object and
reliably provide hardlink information. The UNIX world has relied upon
this
for decades. A filesystem with
On Wed, 2007-01-03 at 14:35 +0200, Benny Halevy wrote:
Believe it or not, but server companies like Panasas try to follow the
standard
when designing and implementing their products while relying on client vendors
to do the same.
I personally have never given a rats arse about standards if
On Wed, 3 Jan 2007, Trond Myklebust wrote:
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
> Even for NFSv3 (that doesn't have the unique_handles attribute I think
> that the linux nfs client can do a better job. If you'd have a filehandle
> cache that points at inodes you could maintain a many to one relationship
> from multiple
On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
> Trond Myklebust wrote:
> >
> > On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
> > > Mikulas Patocka wrote:
> >
> > > >BTW. how does (or how should?) NFS client deal with cache coherency if
> > > >filehandles for the same file
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
> Trond Myklebust wrote:
> >
> > On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
> >
> > > As an example, some file systems encode hint information into the
> > > filehandle
> > > and the hints may change over time, another example
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
>
> On Fri, 29 Dec 2006, Trond Myklebust wrote:
>
> > On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
> >> Why don't you rip off the support for colliding inode number from the
> >> kernel at all (i.e. remove iget5_locked)?
> >>
Certainly, but tar isn't going to remember all the inode numbers.
Even if you solve the storage requirements (not impossible) it would
have to do (4e9^2)/2=8e18 comparisons, which computers don't have
enough CPU power just yet.
It is remembering all inode numbers with nlink > 1 and many other
> > Certainly, but tar isn't going to remember all the inode numbers.
> > Even if you solve the storage requirements (not impossible) it would
> > have to do (4e9^2)/2=8e18 comparisons, which computers don't have
> > enough CPU power just yet.
>
> It is remembering all inode numbers with nlink >
On Tue, 2 Jan 2007, Miklos Szeredi wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix
> > > >> It seems like the posix idea of unique doesn't
> > > >> hold water for modern file systems
> > > >
> > > > are you really sure?
> > >
> > > Well Jan's example was of Coda that uses 128-bit internal file ids.
> > >
> > > > and if so, why don't we fix *THAT* instead
> > >
> > > Hmm,
Hi!
> > >> It seems like the posix idea of unique doesn't
> > >> hold water for modern file systems
> > >
> > > are you really sure?
> >
> > Well Jan's example was of Coda that uses 128-bit internal file ids.
> >
> > > and if so, why don't we fix *THAT* instead
> >
> > Hmm, sometimes you
Hi!
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix
On Tue, 2 Jan 2007, Miklos Szeredi wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes
Certainly, but tar isn't going to remember all the inode numbers.
Even if you solve the storage requirements (not impossible) it would
have to do (4e9^2)/2=8e18 comparisons, which computers don't have
enough CPU power just yet.
It is remembering all inode numbers with nlink 1 and many
Certainly, but tar isn't going to remember all the inode numbers.
Even if you solve the storage requirements (not impossible) it would
have to do (4e9^2)/2=8e18 comparisons, which computers don't have
enough CPU power just yet.
It is remembering all inode numbers with nlink 1 and many other
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all (i.e. remove iget5_locked)?
It's
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
Trond Myklebust wrote:
On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
As an example, some file systems encode hint information into the
filehandle
and the hints may change over time, another example is encoding
On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
Trond Myklebust wrote:
On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
Mikulas Patocka wrote:
BTW. how does (or how should?) NFS client deal with cache coherency if
filehandles for the same file differ?
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
Even for NFSv3 (that doesn't have the unique_handles attribute I think
that the linux nfs client can do a better job. If you'd have a filehandle
cache that points at inodes you could maintain a many to one relationship
from multiple
On Wed, 3 Jan 2007, Trond Myklebust wrote:
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all
On Mon, 1 Jan 2007, Jan Harkes wrote:
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
Anyway, cp -a is not the only application that wants to do hardlink
detection.
I tested programs for ino_t collision (I intentionally injected it) and
found that CP from coreutils 6.7 fails
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
> >Anyway, cp -a is not the only application that wants to do hardlink
> >detection.
>
> I tested programs for ino_t collision (I intentionally injected it) and
> found that CP from coreutils 6.7 fails to copy directories but
> BTW. How does ReiserFS find that a given inode number (or object ID in
> ReiserFS terminology) is free before assigning it to new file/directory?
reiserfs v3 has an extent map of free object identifiers in
super-block.
Inode free space can have at most 2^31 extents --- if inode numbers
Mikulas Patocka writes:
[...]
>
> BTW. How does ReiserFS find that a given inode number (or object ID in
> ReiserFS terminology) is free before assigning it to new file/directory?
reiserfs v3 has an extent map of free object identifiers in
super-block. reiser4 used 64 bit object
> The question is: why does the kernel contain iget5 function that looks up
> according to callback, if the filesystem cannot have more than 64-bit
> inode identifier?
Generally speaking, file system might have two different identifiers for
files:
- one that makes it easy to tell whether two
Hi!
If user (or script) doesn't specify that flag, it
doesn't help. I think
the best solution for these filesystems would be
either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the wrong api; the
Hi!
> >>If user (or script) doesn't specify that flag, it
> >>doesn't help. I think
> >>the best solution for these filesystems would be
> >>either to add new syscall
> >>int is_hardlink(char *filename1, char *filename2)
> >>(but I know adding syscall bloat may be objectionable)
> >
> >it's
Hi!
If user (or script) doesn't specify that flag, it
doesn't help. I think
the best solution for these filesystems would be
either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the wrong api;
Hi!
If user (or script) doesn't specify that flag, it
doesn't help. I think
the best solution for these filesystems would be
either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the wrong api; the
The question is: why does the kernel contain iget5 function that looks up
according to callback, if the filesystem cannot have more than 64-bit
inode identifier?
Generally speaking, file system might have two different identifiers for
files:
- one that makes it easy to tell whether two files
Mikulas Patocka writes:
[...]
BTW. How does ReiserFS find that a given inode number (or object ID in
ReiserFS terminology) is free before assigning it to new file/directory?
reiserfs v3 has an extent map of free object identifiers in
super-block. reiser4 used 64 bit object identifiers
BTW. How does ReiserFS find that a given inode number (or object ID in
ReiserFS terminology) is free before assigning it to new file/directory?
reiserfs v3 has an extent map of free object identifiers in
super-block.
Inode free space can have at most 2^31 extents --- if inode numbers
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
Anyway, cp -a is not the only application that wants to do hardlink
detection.
I tested programs for ino_t collision (I intentionally injected it) and
found that CP from coreutils 6.7 fails to copy directories but displays
On Mon, 1 Jan 2007, Jan Harkes wrote:
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
Anyway, cp -a is not the only application that wants to do hardlink
detection.
I tested programs for ino_t collision (I intentionally injected it) and
found that CP from coreutils 6.7 fails
Mikulas Patocka writes:
>
>
> On Fri, 29 Dec 2006, Trond Myklebust wrote:
>
> > On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
> >> Why don't you rip off the support for colliding inode number from the
> >> kernel at all (i.e. remove iget5_locked)?
> >>
> >> It's reasonable
Trond Myklebust wrote:
>
> On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
> > Mikulas Patocka wrote:
>
> > >BTW. how does (or how should?) NFS client deal with cache coherency if
> > >filehandles for the same file differ?
> > >
> >
> > Trond can probably answer this better than me...
Trond Myklebust wrote:
>
> On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
>
> > As an example, some file systems encode hint information into the filehandle
> > and the hints may change over time, another example is encoding parent
> > information into the filehandle and then handles
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()
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()
Trond Myklebust wrote:
On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
As an example, some file systems encode hint information into the filehandle
and the hints may change over time, another example is encoding parent
information into the filehandle and then handles
Trond Myklebust wrote:
On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
Mikulas Patocka wrote:
BTW. how does (or how should?) NFS client deal with cache coherency if
filehandles for the same file differ?
Trond can probably answer this better than me...
As I read it,
Mikulas Patocka writes:
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all (i.e. remove iget5_locked)?
It's reasonable to have either no
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all (i.e. remove iget5_locked)?
It's reasonable to have either no support for colliding ino_t or full
support
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
> Why don't you rip off the support for colliding inode number from the
> kernel at all (i.e. remove iget5_locked)?
>
> It's reasonable to have either no support for colliding ino_t or full
> support for that (including syscalls that
On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
> Mikulas Patocka wrote:
> >BTW. how does (or how should?) NFS client deal with cache coherency if
> >filehandles for the same file differ?
> >
>
> Trond can probably answer this better than me...
> As I read it, currently the nfs client
On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
> As an example, some file systems encode hint information into the filehandle
> and the hints may change over time, another example is encoding parent
> information into the filehandle and then handles representing hard links
> to the same
On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
As an example, some file systems encode hint information into the filehandle
and the hints may change over time, another example is encoding parent
information into the filehandle and then handles representing hard links
to the same file
On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
Mikulas Patocka wrote:
BTW. how does (or how should?) NFS client deal with cache coherency if
filehandles for the same file differ?
Trond can probably answer this better than me...
As I read it, currently the nfs client matches
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all (i.e. remove iget5_locked)?
It's reasonable to have either no support for colliding ino_t or full
support for that (including syscalls that
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all (i.e. remove iget5_locked)?
It's reasonable to have either no support for colliding ino_t or full
support
Mikulas Patocka wrote:
>
>>> This sounds like a bug to me. It seems like we should have a one to one
>>> correspondence of filehandle -> inode. In what situations would this not be
>>> the
>>> case?
>>
>> Well, the NFS protocol allows that [see rfc1813, p. 21: "If two file handles
>> from
>>
> >> It seems like the posix idea of unique doesn't
> >> hold water for modern file systems
> >
> > are you really sure?
>
> Well Jan's example was of Coda that uses 128-bit internal file ids.
>
> > and if so, why don't we fix *THAT* instead
>
> Hmm, sometimes you can't fix the world,
This sounds like a bug to me. It seems like we should have a one to one
correspondence of filehandle -> inode. In what situations would this not be the
case?
Well, the NFS protocol allows that [see rfc1813, p. 21: "If two file handles
from
the same server are equal, they must refer to the same
On Thu, 28 Dec 2006, Arjan van de Ven wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems
are you really sure?
and if so, why don't we fix *THAT* instead, rather than adding racy
syscalls and such that just can't really be used right...
Why don't you
On Dec 28 2006 10:54, Jeff Layton wrote:
>
> Sorry, I should qualify that statement. A lot of filesystems don't have
> permanent i_ino values (mostly pseudo filesystems -- pipefs, sockfs, /proc
> stuff, etc). For those, the idea is to try to make sure we use 32 bit values
> for them and to ensure
Benny Halevy wrote:
Jeff Layton wrote:
Benny Halevy wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the Linux kernel
Arjan van de Ven wrote:
>> It seems like the posix idea of unique doesn't
>> hold water for modern file systems
>
> are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
> and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the world,
Jeff Layton wrote:
> Benny Halevy wrote:
>> It seems like the posix idea of unique doesn't
>> hold water for modern file systems and that creates real problems for
>> backup apps which rely on that to detect hard links.
>>
>
> Why not? Granted, many of the filesystems in the Linux kernel don't
Benny Halevy wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the Linux kernel don't enforce that
they have unique
> It seems like the posix idea of unique doesn't
> hold water for modern file systems
are you really sure?
and if so, why don't we fix *THAT* instead, rather than adding racy
syscalls and such that just can't really be used right...
--
if you want to mail me at work (you don't), use arjan
Mikulas Patocka wrote:
>>> If user (or script) doesn't specify that flag, it doesn't help. I think
>>> the best solution for these filesystems would be either to add new syscall
>>> int is_hardlink(char *filename1, char *filename2)
>>> (but I know adding syscall bloat may be objectionable)
>>
Mikulas Patocka wrote:
If user (or script) doesn't specify that flag, it doesn't help. I think
the best solution for these filesystems would be either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
and if so, why don't we fix *THAT* instead, rather than adding racy
syscalls and such that just can't really be used right...
--
if you want to mail me at work (you don't),
Benny Halevy wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the Linux kernel don't enforce that
they
Jeff Layton wrote:
Benny Halevy wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the Linux kernel
Arjan van de Ven wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the
Benny Halevy wrote:
Jeff Layton wrote:
Benny Halevy wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the
On Dec 28 2006 10:54, Jeff Layton wrote:
Sorry, I should qualify that statement. A lot of filesystems don't have
permanent i_ino values (mostly pseudo filesystems -- pipefs, sockfs, /proc
stuff, etc). For those, the idea is to try to make sure we use 32 bit values
for them and to ensure that
On Thu, 28 Dec 2006, Arjan van de Ven wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
and if so, why don't we fix *THAT* instead, rather than adding racy
syscalls and such that just can't really be used right...
This sounds like a bug to me. It seems like we should have a one to one
correspondence of filehandle - inode. In what situations would this not be the
case?
Well, the NFS protocol allows that [see rfc1813, p. 21: If two file handles
from
the same server are equal, they must refer to the same
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the world,
Mikulas Patocka wrote:
This sounds like a bug to me. It seems like we should have a one to one
correspondence of filehandle - inode. In what situations would this not be
the
case?
Well, the NFS protocol allows that [see rfc1813, p. 21: If two file handles
from
the same server are
If user (or script) doesn't specify that flag, it doesn't help. I think
the best solution for these filesystems would be either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the wrong api; the
>
> If user (or script) doesn't specify that flag, it doesn't help. I think
> the best solution for these filesystems would be either to add new syscall
> int is_hardlink(char *filename1, char *filename2)
> (but I know adding syscall bloat may be objectionable)
it's also the wrong api;
If user (or script) doesn't specify that flag, it doesn't help. I think
the best solution for these filesystems would be either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the wrong api; the
If user (or script) doesn't specify that flag, it doesn't help. I think
the best solution for these filesystems would be either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the wrong api; the
On Fri, Dec 22, 2006 at 12:49:42AM +0100, Mikulas Patocka wrote:
> On Thu, 21 Dec 2006, Jan Harkes wrote:
> >On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
> >>The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend
> >>the kstat.ino field to 64bit and fix those
On Thu, 21 Dec 2006, Jan Harkes wrote:
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
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.
Coda actually uses 128-bit file
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
> 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.
Coda actually uses 128-bit file identifiers internally, so 64-bits
really
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
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.
Coda actually uses 128-bit file identifiers internally, so 64-bits
really
On Thu, 21 Dec 2006, Jan Harkes wrote:
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
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.
Coda actually uses 128-bit file
On Fri, Dec 22, 2006 at 12:49:42AM +0100, Mikulas Patocka wrote:
On Thu, 21 Dec 2006, Jan Harkes wrote:
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
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
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()
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
> >> 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
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
> 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
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
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
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
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().
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()
101 - 199 of 199 matches
Mail list logo
