>
> > Annius Groenink writes:
> > => Unfortunately, this still gives me:
> > =>
> > => iep:/usr/include/linux# mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /mnt/
> xfs
> > => mount: wrong fs type, bad option, bad superblock on /dev/hdb4,
> > => or too many mounted file systems
> > =>
> >
> > Oh yeah - check the syslog output too - the message from mount is
> > useless, but the syslog can be quite informative.
>
>
> Did that. Nothing. Anything I can do to make it more verbose?
>
>
> --
>
> dr Annius V. Groenink
> groenink@xxxxxxxxxxxx
> tel +31 20 888 4126 fax 4001
>
Hi,
I did some code reading, and realtime subvolume is somewhat broken at the
moment, I will add it to my list. Once you get past the mount issue, the
I/O path itself is not going to understand the realtime device too well and
will trample on the rest of your filesystem.
I will not be able to get to this until at least the end of next week (being
on vaction most of the time in between). Feel free to dig around in the code,
and see if you can work out what needs doing, but this will involve changes
to xfs and pagebuf. Specifically, pagebuf bases all of it's I/O off
the dev_t in the inode, for realtime we will need a different dev_t.
I have some rough ideas on how to deal with this - we can extend the
structure used by the pb_bmap call to include a device and use this
for I/O in page_buf_io.c. Secondly, the code infs/xfs/linux/xfs_lrw.c
does not care much about realtime either, this will probably take someone
with access to the Irix source to fix up.
There is probably a few days work by the right people to get realtime into
some sort of shape where it actually does reasonable things. Note though,
that all this gives us is a way to use a different allocation policy for
file data, and a better chance of well formatted and non-fragmented data.
It will still be accessed via the buffered I/O path until we get O_DIRECT
to function.
Hope this does not put you off XFS!
Steve
|