On Wed, May 09, 2007 at 05:54:09PM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > Suspend-resume, eh?
> >
> > There's an immediate suspect. Can you test this specifically for us?
> > i.e. download a known good file set, do some stuff, suspend, resume,
> > then check the files? If it doesn't show up the first time, can
> > you do it a few times just to rule it out?
>
> Well, I've been doing suspend-resume with xfs for a while without
> problems; the problems seem to be recent and easily repeatable. Which
> just means that it could be a new suspend-resume problem, of course.
Ok. I'm just trying to find a relatively simple test case for the
problem - seeing as you seem to be able to reliably reproduce this
we should be able to work out the trigger...
> > If suspend/resume does cause the problem, can you try again but this
> > time please run 'xfs_freeze -f <mtpt>' on the filesystem before
> > suspend, and then 'xfs_freeze -u <mtpt>' after the resume and see if
> > the problem still occurs?
>
> OK, but I tend to find that xfs_freeze ends up locking up large parts of
> the system... (For example, I tried to do the xfs_freeze + lvm snapshot
> thing, but the lvm snapshot just blocked on the frozen filesystem until
> I unfroze it).
Yes, because LVM snapshot freezes the filesystem for you - if you've
already frozen the filesystem the snapshot will block until you unfreeze
it and then it will freeze it itself to take the snapshot.
> But I'll try it out. Hm, is there some script I can
> stick it into?
No idea.....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|