| To: | Stephen Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: Shrinking an XFS filesystem is a crucial feature! |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Sat, 19 Jan 2002 17:49:26 +0100 |
| Cc: | Austin Gonyou <austin@xxxxxxxxxxxxxxx>, Derek Glidden <dglidden@xxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, "Karl M. Hegbloom" <karlheg@xxxxxxxxxxxxxx> |
| In-reply-to: | <3C496C9A.8030204@xxxxxxx> |
| References: | <1011426823.895.6.camel@yog-sothoth> <1011427680.3142.39.camel@UberGeek> <3C496C9A.8030204@xxxxxxx> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
On Sat, Jan 19, 2002 at 06:54:50AM -0600, Steve Lord wrote: > Of the two thinks Karl asked for, the repair change is probably > about a days work for someone who does not know the code. And then > some very careful init script work to make sure the only way you ever > use it is in single user mode followed by an immediate shutdown. Online > repair is the equivalent of pulling the table cloth out from under the > bone china dishes without anyone noticing. With ext2 its a tea party for > 4, with xfs it is a banquet for 100 people. With vxfs it was designed > in from the start. About online fsck: what could work is to use a writable LVM[1] or EVMS snapshot of the filesystem and fsck the snapshot. When you detect an error unmount the main file system (it is unsafe to use now anyways) and fsck it again. -Andi [1] Current LVM needs a small patch to make snapshots writable. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: strange bug in linux-2.4.9-13-xfs, Eric Sandeen |
|---|---|
| Next by Date: | Re: Shrinking an XFS filesystem is a crucial feature!, Austin Gonyou |
| Previous by Thread: | Re: Shrinking an XFS filesystem is a crucial feature!, Stephen Lord |
| Next by Thread: | Re: Shrinking an XFS filesystem is a crucial feature!, Austin Gonyou |
| Indexes: | [Date] [Thread] [Top] [All Lists] |