Hi Jan,
On Mon, Jun 05, 2006 at 02:22:35PM +0300, Jan Wagner wrote:
>
> Hi and thanks for your quick reply!
No worries.
> On Mon, 5 Jun 2006, Nathan Scott wrote:
> > On Mon, Jun 05, 2006 at 09:49:10AM +0300, Jan Wagner wrote:
> > > I saw with the logdev parameter it is possible to specify an external log
> > > device on a separate disk and partition.
> > >
> > > What would be even more interesting for my special purposes is whether
> > > even the file system structure (inodes etc) could be placed on a
> > > different disk?
> >
> > The realtime subvolume will indeed give you this split. See xfs(5)
> > and mkfs/xfs(8) where most doco resides on this.
>
> Thanks for clarifying. That had been a bit unclear to me from the docs.
>
> Also realized only now that xfsctl has to be used to set an empty file's
> realtime bit to really use the rt subvolume, not quite as straightforward
> as I thought. Will have to "correct" my progs a bit.
You can set the rtinherit bit on a directory, and all new files
created there will be automatically written to the realtime device.
Theres also a (probably undocumented, I really only added it for
my own testing) mkfs option which will let you set the rtinherit
bit on the root directory at mkfs time, so all file data will be
allocated on the realtime device from the start.
Finally, it should be a SMOP to allow a realtime device to be
attached to an existing filesystem. Likewise, xfs_fsr could gain
a new option or two that would cause it to pass over a filesystem
and migrate existing data off to realtime (tiny bit of kernel code
needed there to allow that, but not too tricky I think). And if
you get truly adventurous, growing of rt should work but shrinking
will not - however, this is a much simpler problem to solve than
shrinking of the data device. Bonus points if you tackle that :) -
all interesting little research projects if anyone is up for a bit
of a challenge.
cheers.
--
Nathan
|