Hm, even in single user with a RO root filesystem, changing filesystem
on-disk filesystem structures without have them replied in memory looks
dangerous to me, you will keep data consistency since the fs is RO, but how
about memory? You might have a discrepancy between memory and disk metadata
contents causing in-memory only problems?
On Tue, Nov 12, 2013 at 11:13:17AM -0600, Eric Sandeen wrote:
> How dangerous is dangerous?
>
> We could offer the suggestion of a "-d" repair, if we're
> in single-user mode with the root fs mounted readonly.
>
> This change suggests -d to repair any RO mounted fs.
>
> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
> ---
>
> diff --git a/repair/init.c b/repair/init.c
> index c3f380b..a7a7613 100644
> --- a/repair/init.c
> +++ b/repair/init.c
> @@ -97,8 +97,17 @@ xfs_init(libxfs_init_t *args)
> else
> args->isreadonly = LIBXFS_EXCLUSIVELY;
>
> - if (!libxfs_init(args))
> + if (!libxfs_init(args)) {
> + /* would -d be an option? */
> + if (!no_modify && !dangerously) {
> + args->isreadonly = (LIBXFS_ISINACTIVE |
> + LIBXFS_DANGEROUSLY);
> + if (libxfs_init(args))
> + fprintf(stderr,
> +_("Unmount or use -d to repair a read-only mounted filesystem\n"));
> + }
> do_error(_("couldn't initialize XFS library\n"));
> + }
>
> ts_create();
> increase_rlimit();
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
--
Carlos
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
