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

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)

Current List: 1 - 9
Page: [1]