From: Steve French <smfltc@us.ibm.com>
To: linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk
Cc: linux-kernel@vger.kernel.org, jra@samba.org, tridge@samba.org,
staubach@redhat.com
Subject: Re: [PATCH 1/2] handling 64bit values for st_ino]
Date: 10 Nov 2005 10:50:44 -0600 [thread overview]
Message-ID: <1131641444.2281.20.camel@stevef95.austin.ibm.com> (raw)
Al Viro wrote:
>*However*, there's an area where we have a problem: stat64() and
>getdents64() _could_ return 64bit st_ino/d_ino just fine, if not for having
>too narrow field in kstat and argument of filldir_t. As it is, we have
>->getattr() fill struct kstat and the syscall proper copy the contents of
>that struct kstat into user buffer. stat64 has 64bit st_ino; kstat
>field used to set it is only unsigned long.
> Note that it's not just a theory - there are filesystems that
> want 64bit values in st_ino (AFS, for one). There are consumers of
> these values ready to deal with 64bit values - aside of aforementioned
> syscalls, e.g. NFSv3 and NFSv4 are happy with those
The SMB/CIFS networking protocol also returns 64 bit "UniqueIDs" which
are similar to inode numbers and thus CIFS client (and presumably Samba
server) would benefit slightly . This is not just the case for use of
the core CIFS protocol which Windows and various NAS appliances support but
also for mounts to Samba, HP etc. and servers which support the SNIA CIFS
Unix Extensions (struct FILE_UMIX_BASIC_INFO defines the inode number
returned over the wire as 64 bit).
The only problem with cifs using such numbers (instead of locally generated
but unique transient inode numbers) is that servers are allowed
to export above the top of a local mount - therefore it is hard, although
I believe possible, for the client to detect when it is crossing between
two different partitions on the server as it traverses a directory tree
and thus possible that one export could report two inodes with the same
inode number, although different devices, if the server administrator chose
to configure their exports (shares) that way). Support for DFS (transparent
referrals from one directory to one or more UNC names) on more clients
such as cifs would make it easier for server administrators because there
would be less need to export shares that high up in the server's directory tree.
next reply other threads:[~2005-11-10 16:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-10 16:50 Steve French [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-11-10 0:30 [PATCH 1/2] handling 64bit values for st_ino] Al Viro
2005-11-10 12:57 ` Peter Staubach
2005-11-10 13:43 ` Al Viro
2005-11-10 13:52 ` Peter Staubach
2005-11-10 14:04 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1131641444.2281.20.camel@stevef95.austin.ibm.com \
--to=smfltc@us.ibm.com \
--cc=jra@samba.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=staubach@redhat.com \
--cc=tridge@samba.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).