Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*fsck\.xfs\s+proposed\s+improvements\s*$/: 9 ]

Total 9 documents matching your query.

1. fsck.xfs proposed improvements (score: 1)
Author: Mike Ashton <mike@xxxxxxxx>
Date: Tue, 21 Apr 2009 15:23:34 +0100
Hello folks, I've been using XFS as my filesystem of choice for many, many years now and for all the years of, er, joy, I have encountered a few difficulties with filesystem recovery after machine cr
/archives/xfs/2009-04/msg00143.html (10,806 bytes)

2. Re: fsck.xfs proposed improvements (score: 1)
Author: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Tue, 21 Apr 2009 17:09:34 -0500
Well step back a bit, fsck.xfs exists simply to satisfy the initial boot scripts that invokes fsck -t $fs_type. The reason fsck.xfs does nothing and should continue to do nothing is that by the time
/archives/xfs/2009-04/msg00151.html (13,892 bytes)

3. Re: fsck.xfs proposed improvements (score: 1)
Author: Mike Ashton <mike@xxxxxxxx>
Date: Wed, 22 Apr 2009 10:45:27 +0100
Hi Russell (and others reading), and thanks for your reply. Now that's an interesting point; I hadn't seen it quite like that before. It's now very clear to me that there's a semantic inconsistency b
/archives/xfs/2009-04/msg00160.html (9,841 bytes)

4. Re: fsck.xfs proposed improvements (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Wed, 22 Apr 2009 23:45:11 +0200
Most Linux file systems are not very fault tolerant in this sense; e.g. on ext3 you have have to press return and accept lots of scary messages to get through fsck. -Andi -- ak@xxxxxxxxxxxxxxx -- Spe
/archives/xfs/2009-04/msg00165.html (8,104 bytes)

5. Re: fsck.xfs proposed improvements (score: 1)
Author: Mike Ashton <mike@xxxxxxxx>
Date: Thu, 23 Apr 2009 09:49:00 +0100
Perhaps, but anecdotally/subjectively I've never had a ext3 based system fail to boot because I turned it off and on again. I've had this happen with xfs root filesystems about 15 times over the past
/archives/xfs/2009-04/msg00169.html (9,428 bytes)

6. Re: fsck.xfs proposed improvements (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 23 Apr 2009 07:45:25 -0500
<hand_wave> xfs log replay may be more sensitive... </hand_wave> Server environments probably *normally* are in better shape for power consistency, but still... It certainly does sound like an intere
/archives/xfs/2009-04/msg00171.html (11,003 bytes)

7. Re: fsck.xfs proposed improvements (score: 1)
Author: Mike Ashton <mike@xxxxxxxx>
Date: Thu, 23 Apr 2009 15:35:15 +0100
I propose firstly that that behaviour should be configurable by per filesystem tuning, making it possible to set a root filesystem to default to norecovery on a read-only mount. Then non-initrd mount
/archives/xfs/2009-04/msg00172.html (10,909 bytes)

8. Re: fsck.xfs proposed improvements (score: 1)
Author: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Thu, 23 Apr 2009 11:19:45 -0500
Traditional thinking with a journaled filesystem has been that if there is a dirty log then you do not want to risk mounting the filesystem in an inconsistent state an thereby risking a system crash
/archives/xfs/2009-04/msg00174.html (14,464 bytes)

9. Re: fsck.xfs proposed improvements (score: 1)
Author: Mike Ashton <mike@xxxxxxxx>
Date: Fri, 24 Apr 2009 10:21:29 +0100
Although I don't think you're doing anything more dangerous than mounting a non-fsck'd non-journaling filesystem read-only, which is the traditional unix boot method when you're not using initrd, I d
/archives/xfs/2009-04/msg00194.html (10,541 bytes)


This search system is powered by Namazu