Re: Re: RELEASE on "-"

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: RELEASE on "-"

David Shaw
On Tue, May 17, 2005 at 02:35:24PM +0200, Miklos Szeredi wrote:
> > I think doing this would help a lot, since I can then keep track of
> > the original path in the filehandle field and use that to know which
> > file I am working on.  As things stand now, after the unlink step, the
> > file is not really usable any longer.
>
> Yes, but why would you want to use "hard_remove" anyway?  If you don't
> actually remove the file, it's very tricky to handle correctly, since
> another file may be created with the same name, etc...

I understand.  However, this seems inconsistent in the API: if someone
is using hard_remove, the process using the filesystem will get ENOENT
all of a sudden.  It seems better to pass the "-" to the filesystem
and let it at least clean up gracefully.  release does this already
(so I can already do an ungraceful cleanup), but no other operation
does it.

David


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: RELEASE on "-"

Miklos Szeredi
> I've been experimenting with use_ino, as this is needed to support
> "pwd" over NFS.  Is there a size limit for the inode?  ino_t is 64
> bits long ( sizeof(ino_t)==8 ), but using an inode number that is
> larger than 32 bits gets truncated.  For example, if I use inode
> 0x100000001 for a file, when I stat that file, I get back an inode of
> 1.
>
> Any thoughts?

The kernel is the culprit.  It's internal inode representation is
'unsigned long': see 'struct inode' in include/linux/fs.h and 'struct
kstat' in include/linux/stat.h.

The stat64 interface actually supports 64 bit inode numbers ('struct
stat64' in include/asm/stat.h).

So you see the thing is quite convoulted, and I can't really do
anything about it.

Best solution is to get an AMD64 system ;)

Miklos


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: RELEASE on "-"

Miklos Szeredi
In reply to this post by David Shaw
> I understand.  However, this seems inconsistent in the API: if someone
> is using hard_remove, the process using the filesystem will get ENOENT
> all of a sudden.  It seems better to pass the "-" to the filesystem
> and let it at least clean up gracefully.  release does this already
> (so I can already do an ungraceful cleanup), but no other operation
> does it.

OK, but this will only work for read/write/fsync and not for
fstat/fchmod/fchown/ftruncate.  The later will still get ENOENT after
unlink.

Do you think it makes sense to make a subset of the operations work
after unlink?  If so I'll do it.  

Release is special only because open/release pairs are always
balanced, and the filesystem should be able to rely on that even if
using hard_remove.

Thanks,
Miklos


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inodes both 32-bit and 64-bit

David Shaw
In reply to this post by Miklos Szeredi
On Wed, May 25, 2005 at 08:10:46AM +0200, Miklos Szeredi wrote:

> > I've been experimenting with use_ino, as this is needed to support
> > "pwd" over NFS.  Is there a size limit for the inode?  ino_t is 64
> > bits long ( sizeof(ino_t)==8 ), but using an inode number that is
> > larger than 32 bits gets truncated.  For example, if I use inode
> > 0x100000001 for a file, when I stat that file, I get back an inode of
> > 1.
> >
> > Any thoughts?
>
> The kernel is the culprit.  It's internal inode representation is
> 'unsigned long': see 'struct inode' in include/linux/fs.h and 'struct
> kstat' in include/linux/stat.h.
>
> The stat64 interface actually supports 64 bit inode numbers ('struct
> stat64' in include/asm/stat.h).
>
> So you see the thing is quite convoulted, and I can't really do
> anything about it.

I'm not sure I understand here - I am setting _FILE_OFFSET_BITS == 64
so shouldn't stat already be stat64?  Certainly sizeof(ino_t) becomes
8 when I set _FILE_OFFSET_BITS, and is 4 normally.

David


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inodes both 32-bit and 64-bit

Miklos Szeredi
> I'm not sure I understand here - I am setting _FILE_OFFSET_BITS == 64
> so shouldn't stat already be stat64?  Certainly sizeof(ino_t) becomes
> 8 when I set _FILE_OFFSET_BITS, and is 4 normally.

Yes.  The interface is 64 bit, but that doesn't help you, because
inside the kernel it _has_ to go through a 32 bit variable.

Miklos


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inodes both 32-bit and 64-bit

David Shaw
On Wed, May 25, 2005 at 03:10:50PM +0200, Miklos Szeredi wrote:
> > I'm not sure I understand here - I am setting _FILE_OFFSET_BITS == 64
> > so shouldn't stat already be stat64?  Certainly sizeof(ino_t) becomes
> > 8 when I set _FILE_OFFSET_BITS, and is 4 normally.
>
> Yes.  The interface is 64 bit, but that doesn't help you, because
> inside the kernel it _has_ to go through a 32 bit variable.

Interesting!  There are various filesystems for Linux that claim
64-bit inodes, and they certainly run on 32-bit machines.  I wonder
how they do it - some internal lookup table when they get a collision?

David


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inodes both 32-bit and 64-bit

Miklos Szeredi
> Interesting!  There are various filesystems for Linux that claim
> 64-bit inodes, and they certainly run on 32-bit machines.  I wonder
> how they do it - some internal lookup table when they get a collision?

Don't know.

For example I know that reiserfs uses 64 bit inode numbers.  But it is
careful to allocate them in a way that the lower 32 bits will still be
unique.  So the rest of the bits are just for helping find the inode
on disk.

I don't think the kernel guarantees, that it will return different
st_ino values for different files, although some apps seem to rely on
this, so filesystems will be careful not to break this assumption.

Miklos


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inodes both 32-bit and 64-bit

David Shaw
On Wed, May 25, 2005 at 03:24:29PM +0200, Miklos Szeredi wrote:

> > Interesting!  There are various filesystems for Linux that claim
> > 64-bit inodes, and they certainly run on 32-bit machines.  I wonder
> > how they do it - some internal lookup table when they get a collision?
>
> Don't know.
>
> For example I know that reiserfs uses 64 bit inode numbers.  But it is
> careful to allocate them in a way that the lower 32 bits will still be
> unique.  So the rest of the bits are just for helping find the inode
> on disk.
>
> I don't think the kernel guarantees, that it will return different
> st_ino values for different files, although some apps seem to rely on
> this, so filesystems will be careful not to break this assumption.

Yes, in researching this I found a number of programs that rely on it.
cp and tar both use inode numbers to detect hard linked files, and
getcwd() on BSD platforms use it to figure out the true path the the
cwd.

David


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...