At Thu, 13 Apr 2000 11:19:00 -0500 (CDT),
Jim Mostek <mostek@xxxxxxx> wrote:
>
>
>
> I would like to see XFS mount as root before we worry about handling a
> read-only device. Also, we need to see how XFS handles "file system
> SHUTDOWN" after the read-only mount. In this case, xfs_repair should be
> run on the file system (instead of fsck) and then mounted. This is the way
> Linux does things, right?
>
> Once we have root working, let's see what happens on read-only device.
>
> If XFS burned on a read-only device, recovery should say nothing to do
> and not try to write it. Right?
Just as a FYI
CD-ROMS require a fixed size block.
the only XFS file system that would work on a CD-ROM would
be 512 byte based.
Or if XFS used all 2k blocks.
>
> Jim
>
> >
> >
> >This in itself looks reasonable, but Stephen Tweedie mentioned detecting
> >read only devices and refusing to do the recovery - and that there was
> >code which did this in the latest ext3 cut.
> >
> >Not sure if this is worth following up on with XFS, since XFS refuses
> >to fit on a floppy, it means XFS on an LS120 (or some other media) or
> >someone burned a filesystem needing recovery onto a cdrom. If there is
> >a simple test we can make for read only media then it is probably worth
> >adding, if it is complex then probably not.
> >
> >Steve
> >
> >> On Apr 11, Phil Schwan wrote:
> >> > In somewhat-related news, I have a patch for doing recovery in
> >> > read-only mode that I will test tomorrow. If it works on both
> >> > internal and external logs, I'll send it along for review.
> >>
> >> This appears to do the Right Thing. I flip off the machine in the
> >> middle of a large write, mount it read-only, and it happily plays the
> >> log back (as far as I can tell). Since I'm still dealing with the
> >> helpdesk to get my internal network access fixed, I'm not sure if
> >> there are "real" log replay tests available.
> >>
> >> RCS file: /cvs/linux-2.3-xfs/linux/fs/xfs/xfs_log_recover.c,v
> >> retrieving revision 1.170
> >> diff -u -r1.170 xfs_log_recover.c
> >> --- xfs_log_recover.c 2000/04/06 01:26:24 1.170
> >> +++ xfs_log_recover.c 2000/04/13 14:58:00
> >> @@ -3334,6 +3335,7 @@
> >> {
> >> daddr_t head_blk, tail_blk;
> >> int error;
> >> + xfs_mount_t *mp;
> >>
> >> if (error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))
> >> return error;
> >> @@ -3343,13 +3345,24 @@
> >> head_blk = HEAD_BLK;
> >> tail_blk = TAIL_BLK;
> >> #endif
> >> - /*
> >> +
> >> + /* There used to be a comment here:
> >> + *
> >> * disallow recovery on read-only mounts. note -- mount
> >> * checks for ENOSPC and turns it into an intelligent
> >> * error message.
> >> - */
> >> - if (readonly)
> >> - return ENOSPC;
> >> + *
> >> + * ...but this is no longer true. Now, unless you specify
> >> + * NORECOVERY (in which case this function would never be
> >> + * called), it enables read-write access long enough to do
> >> + * recovery.
> >> + */
> >> + if (readonly) {
> >> + cmn_err(CE_WARN, "XFS: temporarily enabling
> >> read/writ
> >e access for log recovery.\n");
> >> + mp = log->l_mp;
> >> + XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
> >> + }
> >> +
> >> #ifdef _KERNEL
> >> #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
> >> cmn_err(CE_NOTE,
> >> @@ -3365,6 +3378,8 @@
> >> #endif
> >> error = xlog_do_recover(log, head_blk, tail_blk);
> >> log->l_flags |= XLOG_RECOVERY_NEEDED;
> >> + if (readonly)
> >> + XFS_MTOVFS(mp)->vfs_flag |= VFS_RDONLY;
> >> }
> >> return error;
> >> } /* xlog_recover */
> >>
> >> Let me know if you notice trouble--this seems deceptively simple.
> >>
> >> -Phil
> >
> >
|