From: Eric Sandeen <sandeen@sandeen.net>
To: Les Oxley <les@ampex.com>
Cc: xfs@oss.sgi.com
Subject: Re: EXTENT BOUNDARIES
Date: Fri, 19 Jan 2007 22:34:37 -0600 [thread overview]
Message-ID: <45B19BDD.2050808@sandeen.net> (raw)
In-Reply-To: <45B137CA.3020206@ampex.com>
Les Oxley wrote:
>
> Hello,
>
> We are looking into running XFS on a 3TB FLASH MEMORY MODULE. We have a
> question regarding the extent boundaries.
> See the attached PowerPoint drawing, xfs.ppt We are running Linux.
> Our media is 3 million contiguous 4KB blocks. We would like to define
> an extent size of 1MB and this tracks the erasure block size
> of the flash memory, and that greatly improves perfomance. We are trying
> to understand where XFS places the extent boundaries with reference to
> the contiguous block sequence.
> Is this deterministic as indicated in the drawing ? That is, are the
> extent boundaries on 256 block boundaries.
>
> Any help would be greatly appreciated.
>
> Les Oxley
> Ampex Corporation
> Redwood City
> California.
extents by definition land on filesystem block boundaries, and can in
general be any number of filesystem blocks, starting & ending most
anywhere on the block device.
If you wish to always allocate in 1m chunks, you might consider using
the xfs realtime subvolume, see the extsize description in the mkfs.xfs
man page. I'm not sure how much buffered IO to the realtime subvol has
been tested; pretty sure it works at this point, though the sgi guys
will correct me if I'm wrong... it's not exactly the normal mode of
operation.
Using the realtime subvol, however, all your file -metadata- will still
be allocated on the main data volume, in much smaller pieces.
-Eric
next prev parent reply other threads:[~2007-01-20 4:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-19 21:27 EXTENT BOUNDARIES Les Oxley
2007-01-20 3:44 ` Chris Wedgwood
2007-01-20 4:34 ` Eric Sandeen [this message]
2007-01-23 3:08 ` Barry Naujok
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=45B19BDD.2050808@sandeen.net \
--to=sandeen@sandeen.net \
--cc=les@ampex.com \
--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