Thank you for an answer.
Is it force recovery of mount by the dummy log (xfs_fs_log_dummy)
written at the time of freezing?
However, henceforth [ 2.4.10 ], since the dummy log is not written,
recovery does not run it...
----- Original Message -----
From: "Eric Sandeen" <sandeen@xxxxxxx>
To: "Motonari Ishibashi" <ishibashi@xxxxxxxxxxxxxxxxxx>
Sent: Saturday, November 17, 2001 5:19 AM
Subject: Re: Filesystem freeze problem?
> Hi -
> What you are seeing here is that xfs_freeze does not push out the unlink
> list. If you mount and unmount the copied filesystem on /dev/hda7, it
> should delete these remaining files when it replays the log, and a
> subsequent xfs_repair on /dev/hda7 should show no errors.
> On Fri, 2001-11-16 at 02:27, Motonari Ishibashi wrote:
> > Hi,
> > When I used xfs_freeze(8), there was a problem. (at 2.4.10)
> > I used TP which creates a file continuously and tried to create
> > 100000 files. (1 file 1000 byte)
> > The file system was frozen in the neighborhood which created
> > about 5000 files. (To of course, the midst to which TP is operating)
> > The problem was generated after copying the device which created the file
> > to another device.
> > The operation at that time and the result are as follows:
> > /dev/hda6 on /XFS
> > # Run the TP
> > # xfs_freeze -f /XFS (TP is not finished yet.)
> > # dd if=/dev/hda6 of=/dev/hda7
> > # xfs_repair -n /dev/hda7
> > Phase 1 - find and verify superblock
> > <snip>
> > Phase 6 - check inode connectivity...
> > - moving disconnected inodes to lost+found ...
> > disconnected dir inode 524416, would move to lost+found
> > disconnected dir inode 531586, would move to lost+found
> > disconnected inode 531587, would move to lost+found
> > disconnected dir inode 2627558, would move to lost+found
> > more ...
> > ...
> > Why?
> > Please give some information.
> > Cheers.
> > ------------
> > Motonari
> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
> sandeen@xxxxxxx SGI, Inc.