xfs
[Top] [All Lists]

Re: Realtime Section - XFS

To: linux-xfs@xxxxxxxxxxx
Subject: Re: Realtime Section - XFS
From: alan@xxxxxxxxx
Date: Thu, 07 Jun 2001 15:19:15 -0400 (EDT)
In-reply-to: <200106071849.f57IneL29201@xxxxxxxxxxxxxxxxxxxx>
References: <200106071849.f57IneL29201@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: http://webmail.cotse.com/webmail/ - Public ad free privacy shield.
        Can I use and benefit from an rt section without making a specific inode
realtime?  Or does it only benefit inodes that have been made 'realtime'.  Does
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

Quoting Steve Lord <lord@xxxxxxx>:

> 
> The realtime subvolume is indeed there on Linux, you can make them,
> mount
> them, if you know the correct ioctl call you can make an inode
> realtime,
> it is XFS_IOC_FSSETXATTR, and you need to pass in a struct fsxattr 
> with fsx_xflags set to XFS_XFLAG_REALTIME and fsx_extsize set to some
> value (the unit of allocation for realtime space).
> 
> HOWEVER, if you do I/O to this inode then you will hit the wrong
> partition
> on the disk and corrupt your filesystem. I have some code which I think
> will
> fix this, but I have not had a chance to test it yet - it does not break
> the
> rest of xfs though. Even with this code you will have to use direct
> I/O.
> 
> I can package up the code if someone wants to play with it - it should
> not
> corrupt other filesystems, but it could well crash your box. I am not
> ready
> to check it into the tree yet.
> 
> And yes, GRIO is a lot more work, and I would debate it being worth the
> effort
> except as an academic exercise for people who like coding.
> 
> Steve
> 
> > 
> >     Has anyone tried to use linux xfs's realtime section support?
> although 
> > not
> > publicised, it is there, just manually add 'CONFIG_XFS_RT' to .config
> in the
> > root of your kernel sources.  I did finally get this to work, on an
> lvm,
> > mounting /dev/vol/xfs with the option of rtdev=/dev/vol/xfsrt, and at
> mkfs
> > creation time I did not specify extent size.  The realtime device is
> the same
> > size as the main volume, although I do not think this is necessary per
> se, th
> > ey
> > are small, 100M in size, just to test.  So far I am looking for as
> much
> > information I can find about realtime volumes, before building a
> system that
> > would heavily use them.  Would there be any issues with dumping this
> filesyst
> > em?
> > I am not sure, but I believe some attribute needs to be set on files
> to use t
> > he
> > realtime section, as far as speed is concerned.  I am still confused a
> bit on
> > this though, so if someone knows, please let me know.  Compiling the
> kernel w
> > ith
> > this option went without event, some normal warnings is all.  This
> seems stab
> > le,
> > although I do not see why it is not enabled even experimentally in the
> regula
> > r
> > configuration tools.  Getting GRIO to work with linux would take more
> doing I
> > suppose, and is maybe a 2.5.x kernel subject.  On an IRIx 6.5 machine,
> I saw
> > /dev/root mounted with the option 'raw=/dev/rroot'. Is this the
> realtime sect
> > ion
> > of a IRIX system,.. what looks like a raw device?
> > 
> > Any input or help in this arena would be appreciated, I have found
> precious
> > little information on it.
> > 
> > Alan Willis
> > alan@xxxxxxxxx
> 
> 
> 

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