>
> > *** /usr/tmp/TmpDir.15204-0/linux/fs/xfs/linux/xfs_super.c_1.86 Fri Sep 8
15:31:09
> > 2000
> > --- linux/fs/xfs/linux/xfs_super.c Fri Sep 8 14:44:54 2000
> > ***************
> > *** 565,570 ****
> > --- 565,573 ----
> > PVFS_SYNC(vfsp->vfs_fbhv,
> > SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE,
> > sys_cred, error);
> > + PVFS_SYNC(vfsp->vfs_fbhv,
> > + SYNC_ATTR|SYNC_WAIT|SYNC_CLOSE,
> > + sys_cred, error);
> > if (error) {
> > sb->s_flags=save;
> > printk("XFS: Failed to sync for read-only remount\n");
>
> but why this should help - i never got the "XFS: Failed to sync .."
> line ... ok but maybe PVFS_SYNC does not do it's job completely
> all the time - is that the idea?
The issue here is not a failure, but the fact that there is some code in
XFS at the moment which effectively makes a complete sync out of the
filesystem take two sync calls, so currently the Unix myth about typing
sync twice is actually true for XFS!
This is not a problem doing a regular unmount, it only relates to the
hoops we are making XFS jump through to make it remount read-only, not
something it ever does on Irix.
This relates to how we get unlinked files out of the system. We need to flush
the inode to disk in a 'free' state, and we need to remove the inode from an
on disk list of unlinked inodes. The second cannot happen before the first has
completed. In order to keep sync processing time down to a minimum in normal
operation these are handled in two passes.
>
> btw. i redid all on my machine at home: rebuild the tools after a
> make realclean, built a fresh kernel (sources from friday 8.9.)
> and re-mkfs.xfs'ed the filesystems - so far i was not able to
> reproduce the problem again - but i will keep an eye on it
> and try this patch then ... will do the same procedure as
> above now for the two testmachines here at work too
>
> but what i discovered was something i remembered having read about
> being fixed a few days ago (but could not find it in the mails):
> after running xfs_repair on an (unmounted) xfs fs - mounting
> it directly after that - unmounting it again ... now a new
> mount try fails with log problems - running xfs_repair
> (which does not find any errors) fixes the problem
> so the fs is mountable after that ... it also
> works in normal use (without the mount short
> after the xfs_repair) ... but i'll look at
> it closer and give more details (btw. all
> the stuff was from fri 8.9. so _after_ i
> read about the fix)
Ugh!, I will give this a try.
Steve
>
> t
>
> --
> thomas.graichen@xxxxxxxxxxxxx
> technical director innominate AG
> clustering & security networking people
> tel: +49.30.308806-13 fax: -77 http://innominate.de
|