Are there userspace utilities to enable this realtime inode io behavior?
Quoting Steve Lord <lord@xxxxxxx>:
> >
> > Can I use and benefit from an rt section without making a specific
> inod
> > e
> > realtime? Or does it only benefit inodes that have been made
> 'realtime'. Do
> > es
> > it have any specific overall fs performance effect? My test is small,
> so it
> > is
> > fast anyway. also, is there any size guideline to the sizes of rt
> sections vs
> > size of the data and log sections? Or does it only matter to the
> inodes that
> > are used in a realtime fashion?
> >
> > Alan Willis
> > alan@xxxxxxxxx
> >
>
> The realtime subvolume is where data for realtime inodes is allocated,
> so yes
> it only applies to those. Create a new file, make it realtime, and then
> do
> I/O to it. Realtime is a little bit of a misnomer, the differences
> are:
>
> o There is only data in the partition, all metadata remains the the
> data
> subvolume. If you put the partitions in the correct place then the
> only
> time headseeks happen is to go and get actual data, no log or
> metadata
> I/O to get in the way.
>
> o A different space allocator is used, it uses a binary chop type
> approach
> to disk space which is wasteful, but which means it is very hard to
>
> fragment the files on realtime partitions. This allocator is also
> faster
> and tends to allocate space in a more deterministic amount of
> time.
>
> o When you make the filesystem, and when you create a realtime file
> via the
> ioctl call you can specify an extent size, all allocations will be
> a
> multiple of this. I have my doubts that this will work as
> advertised yet
> on linux.
>
> These are all supposed to add up to something which is good for doing
> streaming
> I/O, typically of very large files such as video data.
>
> Here are the changes I have to at least attempt to send disk I/O to the
>
> realtime device.
>
> Users of realtime on Irix would probably create a filesystem which was
> almost
> all realtime space, you still need the regular partition for the log and
> the
> metadata.
>
> Steve
>
>
>
>
|