All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Daire Byrne <daire.byrne@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: Contiguous file sequences
Date: Sun, 26 Sep 2010 23:08:57 -0500	[thread overview]
Message-ID: <4CA018D9.1030803@sandeen.net> (raw)
In-Reply-To: <AANLkTinz4rYCb8cHH69pYy-oPT-041y+DmVaWm3N_1hu@mail.gmail.com>

Daire Byrne wrote:
> Eric,
> 
> On Wed, Sep 22, 2010 at 9:10 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
>> Daire Byrne wrote:
>>> Hi,
>>>
>>> I have been trying to figure out how to lay down a file sequence (e.g.
>>> images) such that they are guaranteed to always be contiguous on disk
>>> (i.e. no block gaps between them).
>> There's no mechanism to guarantee that.
>>
>> Why is this the goal, what are you trying to achieve?
> 
> I am essentially trying to play back a large frame sequence and trying
> to minimise seeks as it can lead to sporadic slowdowns on a SATA based
> RAID.

Ok - and you've really seen allocation patterns that cause the playback
to slow down?  xfs_bmap information for a few sequential files that were
this far off would be interesting to see.

Are you certain that it's seekiness causing the problem?  A great way
to visualize it would be to use the seekwatcher application while you
run a problematic file sequence.

...

>> You can't specify a starting block for any given file I'm afraid.
> 
> Somebody pointed me at this which looks fairly promising:
> 
>   http://oss.sgi.com/archives/xfs/2006-07/msg01005.html

Yeah, that never got merged, but I think it still could be.

It's only half your battle though, you need to find that contiguous
space first, then specify the start block for it with the interface
above.

> I'm still trying to get my head around how I would actually write a
> userspace app/script to use it but I think it should allow me to do
> what I want. It would be good if I could script it through xfs_io. I'd
> really like a script where I could point it at a directory and it
> would do something like:
> 
>   1. count total space used by file sequence
>   2. find start block for that much contiguous space on disk (or as
> much of it as possible)
>   3. allocate the files using the start block one after another on disk
> 
>>> Another option might be to create a single contiguous large file,
>>> concatenate all the images into it and then split it up on disk using
>>> offsets but I don't think such a thing is even possible? I always know
>>> the image sequence size beforehand, all images are exactly the same
>>> size and I can control/freeze the filesystem access if needed.
>>>
>>> Anybody got any suggestions? It *seems* like something that should be
>>> possible and would be useful.
>> This would be pretty low-level control of the allocator by userspace.
>>
>> I'll just go back and ask what problem you're trying to solve?  There
>> may be a better (i.e. currently existing) solution.
> 
> The "realtime" option is sometimes suggested as a way to do sequence
> streaming but I'd really rather avoid that. It seems to me like the
> option to allocate a sequence of files end on end in a known chunk of
> contiguous space is something that would be useful in the normal
> operating mode.

It would be, but it's not there now.  Also, without some more complexity
it'd still probably end up being a best effort rather than a guarantee,
but some hints from userspace might be better than nothing.

-ERic

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

  reply	other threads:[~2010-09-27  4:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-22 11:01 Contiguous file sequences Daire Byrne
2010-09-22 20:10 ` Eric Sandeen
2010-09-24 10:43   ` Daire Byrne
2010-09-27  4:08     ` Eric Sandeen [this message]
2010-09-27 16:30       ` Daire Byrne
2010-09-27 18:35         ` Matthias Schniedermeyer
2010-09-28  1:16         ` Dave Chinner
2010-09-27 20:56       ` Roger Willcocks
2010-09-25  9:42   ` Michael Monnerie
2010-09-22 20:50 ` Matthias Schniedermeyer
2010-09-22 22:36   ` Dave 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=4CA018D9.1030803@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=daire.byrne@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.