At Thu, 13 Apr 2000 14:16:57 -0400,
Phil Schwan <phil@xxxxxxxxxxxxx> wrote:
>
>
> On Apr 13, Steve Lord wrote:
> > 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.
>
> Here we go, try this out for size.
>
> By the way, Russell, what's the best way to #include linux/fs.h here?
> I'm still fuzzy on how the new arch-specific #includes work for
> includes that aren't needed by every source file.
First it would be best not to include linux/fs.h in any file
not in the fs/xfs/linux directory. It will cause headaches.
If fact that linux/xfs_sema.h shouldn't be there either.
Second... xfs includes files needed by a particular xfs_*.c
file can be included directly.
If the file is general enough say types.h it can go
in xfs_os_defs.h; I doesn't really hurt if some
*.c files include some header files they don't need.
As long as it doesn't create conflicts.
if you really really need to include fs.h put it
in xfs_os_defs.h with an
#ifdef NEED_FS_H wrapper.
then define it in what ever file that it is needed.
A better thing to do would be to move any code
that uses linux specific "stuff" into a file in
fs/xfs/linux/
Then just insert a function call from wherever.
You may need to make this a macro that calls
X for kernel and nothing for user land.
Remember lib sim compiles in user land and
typically breaks when kernel land
includes are used.
>
> Index: xfs_log_recover.c
> ===================================================================
> 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 17:23:17
> @@ -44,6 +44,7 @@
> #include <sys/sysmacros.h>
> #include "xfs_buf.h"
> #include <linux/xfs_sema.h>
> +#include <linux/fs.h>
> #include <sys/vnode.h>
> #include <sys/debug.h>
> #include <sys/cmn_err.h>
> @@ -3334,6 +3336,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 +3346,30 @@
> 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) {
> + printk(KERN_ERR "XFS: WARNING: recovery required on
> readonly filesystem.\n");
> + mp = log->l_mp;
> + if (is_read_only(mp->m_dev) ||
> + is_read_only(mp->m_logdev)) {
> + printk(KERN_ERR "XFS: write access unavailable,
> cannot proceed.\n");
> + return -EROFS;
> + }
> + printk(KERN_ERR "XFS: write access will be enabled
> during recovery.\n");
> + XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
> + }
> +
> #ifdef _KERNEL
> #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
> cmn_err(CE_NOTE,
> @@ -3365,6 +3385,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 */
>
> I have internal access now, thanks to the terrific helpdesk people.
> All rejoice.
>
> --
> Phil Schwan, Captain Popetastic, Linuxcare Canada
|