From: Nathan Scott <nscott@aconex.com>
To: "Raz Ben-Jehuda(caro)" <raziebe@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: [DISCUSS] xfs allocation bitmap method over linux raid
Date: Thu, 25 Jan 2007 09:38:13 +1100 [thread overview]
Message-ID: <1169678294.18017.200.camel@edge> (raw)
In-Reply-To: <5d96567b0701232234y2ff15762sbd1aaada5c3a0a0@mail.gmail.com>
Hi Raz,
On Wed, 2007-01-24 at 08:34 +0200, Raz Ben-Jehuda(caro) wrote:
> David Hello.
> I have looked up in LKML and hopefully you are the one to ask in
> regard to xfs file system in Linux.
> My name is Raz and I work for a video servers company.
OOC, which one? (would be nice to put an entry for your company
on the http://oss.sgi.com/projects/xfs/users.html page).
> These servers demand high throughput from the storage.
> We applied XFS file system on our machines.
>
> A video server reads a file in a sequential manner. So, if a
Do you write the file sequentially? Buffered or direct writes?
> file extent size is not a factor of the stripe unit size a sequential
> read over a raid would break into several small pieces which
> is undesirable for performance.
>
> I have been examining the bitmap of a file over Linux raid5.
I've found that, in combination with Jens Axboe's blktrace toolkit
to be very useful - if you have a sufficiently recent kernel, I'd
highly recommend you check out blktrace, it should help you alot.
(bmap == block map, theres no bitmap involved)
> According to the documentation XFS tries to align a file on
> stripe unit size.
>
> What I have done is to fix the bitmap allocation method during
> the writing to be aligned by the stripe unit size.
Thats not quite what the patch does, FWIW - it does two things:
- forces allocations to be stripe unit sized (not aligned)
- and, er, removes some of the per-inode extsize hint code :)
> /d1/rt/kernels/linux-2.6.17-UNI/fs/xfs/xfs_iomap.c
> linux-2.6.17-UNI/fs/xfs/xfs_iomap.c
> --- /d1/rt/kernels/linux-2.6.17-UNI/fs/xfs/xfs_iomap.c 2006-06-18
> 01:49:35.000000000 +0000
> +++ linux-2.6.17-UNI/fs/xfs/xfs_iomap.c 2006-12-26 14:11:02.000000000 +0000
> @@ -441,8 +441,8 @@
> if (unlikely(rt)) {
> if (!(extsz = ip->i_d.di_extsize))
> extsz = mp->m_sb.sb_rextsize;
> - } else {
> - extsz = ip->i_d.di_extsize;
> + } else {
> + extsz = mp->m_dalign; // raz fix alignment to raid stripe unit
> }
The real question is, why are your initial writes not being affected by
the code in xfs_iomap_eof_align_last_fsb which rounds requests to a
stripe unit boundary? Provided you are writing sequentially, you should
be seeing xfs_iomap_eof_want_preallocate return true, then later doing
stripe unit alignment in xfs_iomap_eof_align_last_fsb (because prealloc
got set earlier) ... can you trace your requests through the routines
you've modified and find why this is _not_ happening?
cheers.
--
Nathan
next prev parent reply other threads:[~2007-01-24 22:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-24 6:34 [DISCUSS] xfs allocation bitmap method over linux raid Raz Ben-Jehuda(caro)
2007-01-24 22:38 ` Nathan Scott [this message]
2007-01-28 10:32 ` Raz Ben-Jehuda(caro)
2007-01-28 21:49 ` Nathan Scott
2007-01-29 21:49 ` Nathan Scott
2007-01-28 23:52 ` David Chinner
2007-01-24 22:58 ` David Chinner
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=1169678294.18017.200.camel@edge \
--to=nscott@aconex.com \
--cc=raziebe@gmail.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 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.