All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Cc: Christoph Hellwig <hch@infradead.org>
Subject: Re: XFS, NFS and inode64 on 2.6.27
Date: Sat, 21 Nov 2009 22:17:57 +0100	[thread overview]
Message-ID: <200911212217.57407@zmi.at> (raw)
In-Reply-To: <20091121131657.GA2095@infradead.org>


[-- Attachment #1.1: Type: Text/Plain, Size: 1951 bytes --]

On Samstag, 21. November 2009 Christoph Hellwig wrote:
> So your NFS exports are not the roots of their respsective
>  filesystems? 

That's the way it works with NFSv4. You create an NFS root dir with a 
special entry in /etc/exports:
/nfsserver 10.0.0.0/8(fsid=0,rw,insecure,no_subtree_check,crossmnt)

and if you want other parts exported, create a dir there and mount it:
mkdir /nfsserver/data
mount --bind /mydata /nfsserver/data

This just takes the inodes from there and creates something like a view 
into this dir. From the client, you

mount -t nfs4 server:/data /serverdata
and you get the /nfsserver/data mounted there.

>  This means NFSD uses non-standard filesystem IDs in the
>  filehandles which have to encode the inode number of the export
>  root.  Your best option is to simplify switch to exporting a whole
>  filesystem, 

That's how it worked until NFSv3. I tried that also, didn't work either.
The whole thing worked before I reinstalled it (this server now runs 
virtualized within XENserver), and maybe that made some subdirs have 
inodes > 32bit.

>  alternatively you can try making sure NFSD uses the
>  16byte wide UUID style export.  

How'd I do that?

>  Note thast either way will only work
>  with a 64bit kernel as the fs has no say in encoding the filesystem
>  part of the handle and ino_t is always 32bit on 32bit platforms. 
>  This will also affect any other filesystem with 64bit inode numbers.

Not my problem, everything 64bit here. I use the kernel-nfsd, and that's 
why I was wondering to have this problem.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2009-11-21 21:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-20 10:52 XFS, NFS and inode64 on 2.6.27 Michael Monnerie
2009-11-20 21:23 ` Nathaniel W. Turner
2009-11-21 10:47   ` Michael Monnerie
2009-11-21 13:16 ` Christoph Hellwig
2009-11-21 21:17   ` Michael Monnerie [this message]
2009-11-22 12:31     ` Christoph Hellwig
2009-11-23 13:19 Michael Monnerie
     [not found] ` <200911231419.50678-xqLQU7OFoCs@public.gmane.org>
2009-11-23 15:51   ` J. Bruce Fields
2009-11-25 21:13     ` Christoph Hellwig
2009-11-25 23:55       ` J. Bruce Fields

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=200911212217.57407@zmi.at \
    --to=michael.monnerie@is.it-management.at \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.com \
    /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.