Steve Lord <lord@xxxxxxx> wrote:
> It all depends on when you last downloaded the code. For a few weeks, probably
> since early July we have actually had a serious bug in the kernel which
> caused us to flush inodes to disk incorrectly. This was fixed within the
> last couple of days and should be in the cvs tree now. This bug would
> certainly cause the type of problem you report from xfs_repair. Prior to
> that there were also issues with removing files which caused similar
> repair output - this is also fixed.
i'am using an rsynced copy of the xfs cvs tree here - rsynced each morning
and also use fresh checkouts out of it for testing - the one with the
problems was i think from about last friday (and most probably had
the bug in it) - i just chout/built a new one and will observe
it now :-)
> So as of yesterday, XFS should be behaving again. There are still problems
> we can trigger under stress conditions, by stress I mean 8 threads running
> in parallel on the same filesystem doing nothing but filesystem operations.
> After a couple of hours this managed to hit a multithreading hole.
> While I am at it, here is some other status:
> We have 2.4.0-test5 running in house, we plan to upgrade to this soon,
> probably early next week.
> dump/restore is functioning - I am not sure if this has been pushed out
> to the cvs repository yet. We also have the defragmenter working.
> Extended attributes have been turned on, but have problems at the moment,
> plus the system call interface for that will be changing.
> Please report problems if you come across something. Reports of XFS working
> well for you are also appreciated!
yes i'll do - thanks for the info
t
--
thomas.graichen@xxxxxxxxxxxxx
technical director innominate AG
clustering & security networking people
fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr
|