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?
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
>
>
|