From: Tom McNeal <trmcneal@attbi.com>
To: Eno Compton <Eno.Compton@Miltope.com>,
NFS maillist <nfs@lists.sourceforge.net>
Subject: Re: nfs support of FAT file systems
Date: Tue, 11 Mar 2003 20:39:00 -0800 [thread overview]
Message-ID: <3E6EB9E4.9000504@attbi.com> (raw)
In-Reply-To: B98C57C204171A46BDFA264D6008EE1816C64A@exchange1.miltope.com
Hi -
Here is a more complete answer from Neil Brown, covering the various FAT
file systems. I will be putting a discussion of this into the FAQ, since I
think its
an important issue to a lot of folks:
NFS access to FAT filesystems works for simple cases, starting with the
early 2.4 kernels, but if used extensively can cause grief.
FAT file systems can be exported, but only those operations supported by
that file system will be honoured. *Note* Operations such as "chown",
"link", and "symlink" are not supported by these file systems, and will fail.
Read/write/create etc., should be fine as long as the files remain relatively
unchanged. The FAT filesystem layout does not contain enough
information to create a lasting identity needed for NFS to create persistent
filehandles. For example, If you take a file, rename it to another
directory,
trunctate it, and write new data to it, there is nothing stored in the
filesystem
that can be used to show that the resulting file is, in any sense, the
"same" as
the original file, and there is no way to find the new file given any
details about
the original file. Therefore, the Linux NFS server cannot guarantee that
once you have opened a file, you can continue to have access to that file.
If the file is modified in the ways given above, NFS may be unable to locate
or identify the file correctly, and so may return ESTALE errors. This may
happen if the fileserver is rebooted, or if the fileserver is under heavy
memory
pressure. The only fix which might be applied would require file handle
changes,
and would not completely solve the problem, and would be a lot of work, so it
doesn't look likely at all.
I hope this helps.
Tom
Eno Compton wrote:
> I thank you, Tom, for your trouble.
> Eno
>
> -----Original Message-----
> From: trmcneal@attbi.com [mailto:trmcneal@attbi.com]
> Sent: Monday, March 10, 2003 11:43 AM
> To: Eno Compton
> Subject: Re: nfs??
>
> I believe that is correct. Linux will certainly allow fat32 mounts, but
> exporting one is a different matter. I'll check to make sure.
>
> Regards -
>
> Tom
>
> --
> Tom McNeal
> (650)906-0761(cell)
> (650)964-8459(fax)
>
>>Don't know if it's proper to contact you directly. Hope so. Can't find an
>>answer.
>>I think nfs will not export a fat32 partition under linux. Is that correct?
>
>>Eno Compton
>>
>
--
Tom McNeal
(650)906-0761(cell)
(650)964-8459(fax)
Email: trmcneal@attbi.com
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
parent reply other threads:[~2003-03-12 4:37 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <B98C57C204171A46BDFA264D6008EE1816C64A@exchange1.miltope.com>]
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=3E6EB9E4.9000504@attbi.com \
--to=trmcneal@attbi.com \
--cc=Eno.Compton@Miltope.com \
--cc=nfs@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.