lkml.org 
[lkml]   [2004]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: xfs partition refuses to mount
On Sat, 29 May 2004, Steve Lord wrote:
>Yes, xfs_repair will not replay a log, and if it finds dirty metadata in
>the log it wants you to replay it via mount. Having xfs_repair able to
>replay the log would be handy, but if mount cannot replay it, then
>repair will not either.

Except xfs_repair can be a lot smarter in the process. I would never
suggest putting 3MB worth of log recovery code in the kernel when it's
likely to very be used. Such "fogiving" log recovery belongs in userland.

>The whole reason for -L was customers who automatically ran xfs_repair
>after a crash, and hence threw away anything which was in the log. So
>it is more of a stop and think what you are doing option.

"Don't do that." *grin*

>> There should be a way to instruct the kernel's rootfs mount to not look
>> at the log. I don't know if one can pass any generic mount options at
>> boot. ("ro"/"rw" and rootfs type, but I don't know of any others.) This
>> would be handy for more than just xfs, btw.
>
>You can mount norecovery,ro - but no guarantees that it will stay up
>long. See Documentation/filesystems/xfs.txt for a list of xfs mount
>options.

I know I can tell the userland mount (/sbin/mount) to not replay the log.
But I'm looking for a way to tell the kernel, at boot, to not replay the
log. (digs through kernel) Ahh... 'rootflags=...' is what I'm looking for.

--Ricky


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.068 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site