From: Timothy Shimmin <tes@sgi.com>
To: Richard Scobie <richard@sauce.co.nz>
Cc: xfs@oss.sgi.com
Subject: Re: Filestreams (and 64bit inodes)
Date: Wed, 11 Jun 2008 11:39:35 +1000 [thread overview]
Message-ID: <484F2CD7.9070506@sgi.com> (raw)
In-Reply-To: <484F0998.90306@sauce.co.nz>
Hi Richard,
Richard Scobie wrote:
> Timothy Shimmin wrote:
>
>> BTW, Sam Vaughan wrote some tutorial notes on the allocator and in
>> particular
>> filestreams which I've pasted below:
>> (I thought it might be here:
>> http://oss.sgi.com/projects/xfs/training/ but I can't see it
>> in the allocator lab and slides).
>
> I did actually find an entry for filestreams in slide 6.
>
Yes, so did I but on a quick scan it didn't have the same detail.
> While there I also found the information on 64bit inodes.
>
> My filesystem is 9.6TB and could well end up with a large quantity of
> 1-15MB files stored and the statement:
>
> "Operating system interfaces and legacy software products often mandate
> the use of 32 bit inode numbers even on systems that support 64 bit
> inode numbers."
>
> makes me wonder how common this still is in practice - the slide was
> written in 2006)?
>
> My initial preference would be to go with 64 bit inodes for performance
> reasons, but as one cannot revert the fs back to 32 bit inodes once
> committed, I am somewhat hesitant.
>
> Or am I worrying unecessarily about the negative impact of 32 bit
> inodes, given 9.6TB full of 1 to 15MB files?
>
Ah, the 32 bit inode versus 64 bit inode question :)
I don't have any definitive answers and I'm sure there will be people
on the list with their opinions and experiences.
So just some thoughts...
Firstly, XFS' current support for 32 bit inode numbers was added as
an afterthought I think primarily at the time on IRIX for 32 bit backup
clients such as Legato Networker.
It is only a compatibility thing with performance downsides.
So the question then becomes (1)what exactly is the compatibility matrix
and (2)under what conditions are there performance problems and by how much.
The other thing (3) is then a conversion tool for moving back from 64 bit inodes
to 32 bit inodes if you have a compat problem.
(3) There is a conversion tool called xfs_reno on IRIX. Barry has ported and modified
it for Linux but I believe has not checked it in and has some outstanding
Agami review points to address. Ideally, it would be nicer if we had more
kernel support (as suggested by Dave (dgc)) for swapping all the inode's metadata
(instead of just extents as we currently do).
So in other words, it is not there yet and there is the question of whether
we should update the kernel first (or maybe the tool should go in anyway for
use on older kernels).
(1) It would be nice to know what the state of the apps really are.
There is also the question of interaction with CXFS and NFS.
Greg Banks has a compat matrix for NFS. It looks like the main
things is to get something half recent - linux 2.6, nfs v3,
apps which use 64 bit sys calls (eg. stat64) etc...
Would need to do investigating.
There is also the possibility of other 32bit/64bit mapping schemes for xfs
but I won't go there.
--Tim
next prev parent reply other threads:[~2008-06-11 1:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-07 23:11 Filestreams Richard Scobie
2008-06-09 3:31 ` Filestreams Eric Sandeen
2008-06-10 1:49 ` Filestreams Timothy Shimmin
2008-06-10 2:14 ` Filestreams Richard Scobie
2008-06-10 23:09 ` Filestreams (and 64bit inodes) Richard Scobie
2008-06-11 1:39 ` Timothy Shimmin [this message]
2008-06-11 2:47 ` Richard Scobie
2008-06-11 3:23 ` Eric Sandeen
2008-06-12 13:52 ` Eric Sandeen
2008-06-13 1:28 ` Greg Banks
2008-06-13 3:06 ` Eric Sandeen
2008-06-13 3:24 ` Greg Banks
2008-06-13 3:20 ` Mark Goodwin
2008-06-13 3:40 ` Greg Banks
2008-06-13 3:46 ` Eric Sandeen
2008-06-13 3:57 ` Greg Banks
2008-06-13 5:35 ` Greg Banks
2008-06-13 13:28 ` Eric Sandeen
2008-06-13 3:45 ` Eric Sandeen
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=484F2CD7.9070506@sgi.com \
--to=tes@sgi.com \
--cc=richard@sauce.co.nz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox