Quoting Eric Sandeen <sandeen@xxxxxxx>:
> Want to try this?
> [ Patch to remove xfs_iflush_all call ]
> It certainly speeds up freeze. And it looks like it still
> does what it's supposed to do. :)
Seems to speed everything up here too - after my initial rsync, the
freeze takes next to no time! xfs_repair -n's on a snapshot taken
just after the freeze seem to suggest everything on the filesystem is
consistent too...
[root@toy tst1]# rsync -aH -e ssh root@fs:/home/01/ /tst1/
...
[root@toy tst1]# time xfs_freeze -f /tst1 ; xfs_freeze -u /tst1
real 0m0.882s
user 0m0.000s
sys 0m0.850s
If I then proceed to run a find across the fs, I see a slightly
increased time to run:
[root@toy tst1]# find /tst1 > /dev/null ; time xfs_freeze -f /tst1 ;
real 0m23.288s
user 0m0.000s
sys 0m0.840s
But it returns to normal immediately after that:
[root@toy tst1]# xfs_freeze -u /tst1 ; time xfs_freeze -f /tst1
real 0m0.372s
user 0m0.000s
sys 0m0.370s
I'm guessing that lengthened freeze is caused by having to sync all
the inodes with updated atimes to disk, but as it never exceeds 22
seconds on my filesystem, I'm happy :).
> Incidentally, I think that after your 7 hour freeze, things were
> not in good shape. If I froze, unfroze, then tried to do a
> "find" through the filesystem, it would blow up - apparently
> xfs_iflush_all was disconnecting xfs inodes from the linux
> inodes, and we wound up with null pointer dereferences & oopses.
I must admit, I hadn't actually tried working with the filesystem
after going through a long freeze. I was too busy doing the freeze
again to make sure I could replicate the problem before reporting
it :).
Thanks,
Chris
|