xfs
[Top] [All Lists]

Re: realtime ( was RE: unexpected high fragmentation, any ideas? )

To: Scott Fagg <scott.fagg@xxxxxxxxxxx>
Subject: Re: realtime ( was RE: unexpected high fragmentation, any ideas? )
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 06 Apr 2005 20:49:54 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <2B6FD80A38020542803BA5DC9B3C9754224C7E@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <2B6FD80A38020542803BA5DC9B3C9754224C7E@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324)
Scott Fagg wrote:
Would realtime have any use outside of video-streaming ? What sort of benefit might it offer other apps, e.g. db servers ?


Originally the realtime subvolume was designed for media streaming
applications. It was coupled with another Irix feature called GRIO
or guaranteed rate I/O. Basically a scheme for reserving disk
bandwidth for specific I/O streams. At this time it only supported
O_DIRECT I/O.

There is code in there now to do buffered I/O as well, I cannot say I
have used it at all.

The basic differences are:

 o The realtime device only gets file data I/O, there is no metadata
   on the device at all. You need another partition for this. All the
   inodes, extent information, freespace maps etc live on this
   partition - known as the data subvolume.

 o In order to get a file to live on the realtime subvolume, you have
   to use a special ioctl call on the file descriptor after it is
   opened and before any space is allocated.

 o Space is allocated in muliples of the real time extent size, using
   a different allocator which uses a binary chop algorithm to parcel
   out disk space. i.e. the first inode gets space starting at the
   begining of the space, the second starts in the middle, the third
   goes 25% of the way into the space etc. It tends to do a good job
   of keeping things contiguous.

 o The allocator was also intended to be deterministic, so that the time
   taken to allocate space should always be about the same.

So if you want big fat files which get layed out in one chunk, and spindles where no other I/O gets in the way of the data I/O, then
it can be handy. It does sound like something a database might
like to use.

Steve


<Prev in Thread] Current Thread [Next in Thread>