Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+pseudo\s+OOPs\.\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+pseudo\s+OOPs\.\s*$/: 10 ]

Total 10 documents matching your query.

1. XFS pseudo OOPs. (score: 1): Author:; Date: Mon, 15 Mar 2004 11:38:59 -0600; I don't know, yet, if this is a hardware or a software problem. I'm trying to figure that out. I'm using the ATRpms kernel (2.4.20-30_37 w XFSv1.3.0 et al. see the list at http://atrpms.physik.fu-ber; /archives/xfs/2004-03/msg00167.html (13,873 bytes)
2. Re: XFS pseudo OOPs. (score: 1): Author:; Date: Tue, 16 Mar 2004 16:50:36 +1100; Hi Dan, Looks like you've got filesystem corruption, from your trace it looks like its in one of the freespace btrees in an AG header. Its difficult to diagnose whether this is caused by a hardware o; /archives/xfs/2004-03/msg00168.html (8,923 bytes)
3. Re: XFS pseudo OOPs. (score: 1): Author:; Date: Tue, 16 Mar 2004 07:51:07 -0600; If an md device decided to go wonko would that make it look like a FS corruption? For instance, these FSs are RAID50 (hw raid5, sw raid0) across 3 volumes. I got to thinking about the kernel I've be; /archives/xfs/2004-03/msg00178.html (10,146 bytes)
4. Re: XFS pseudo OOPs. (score: 1): Author:; Date: Tue, 16 Mar 2004 11:41:23 -0600; I just took a look at the extra lvm patch (v1.0.7) that Axel has added to his AT kernel. It's touching fs/buffer.c and fs/super.c as well as [reiser|ext3]/[buffer.c|super.c] but nothing in the xfs tr; /archives/xfs/2004-03/msg00179.html (11,118 bytes)
5. Re: XFS pseudo OOPs. (score: 1): Author:; Date: Wed, 17 Mar 2004 16:05:58 +1100; Hmmm.. not sure what patch that is - maybe the VFS locking patch for LVM snapshots? If so, its unlikely to be the cause here. Does that mean you have a reliable failure/test case? If not, could you t; /archives/xfs/2004-03/msg00189.html (8,307 bytes)
6. XFS pseudo OOPs. (score: 1): Author: >; Date: Mon, 15 Mar 2004 11:38:59 -0600; I don't know, yet, if this is a hardware or a software problem. I'm trying to figure that out. I'm using the ATRpms kernel (2.4.20-30_37 w XFSv1.3.0 et al. see the list at http://atrpms.physik.fu-ber; /archives/xfs/2004-03/msg00557.html (13,873 bytes)
7. Re: XFS pseudo OOPs. (score: 1): Author: >; Date: Tue, 16 Mar 2004 16:50:36 +1100; Hi Dan, Looks like you've got filesystem corruption, from your trace it looks like its in one of the freespace btrees in an AG header. Its difficult to diagnose whether this is caused by a hardware o; /archives/xfs/2004-03/msg00558.html (8,923 bytes)
8. Re: XFS pseudo OOPs. (score: 1): Author: >; Date: Tue, 16 Mar 2004 07:51:07 -0600; If an md device decided to go wonko would that make it look like a FS corruption? For instance, these FSs are RAID50 (hw raid5, sw raid0) across 3 volumes. I got to thinking about the kernel I've be; /archives/xfs/2004-03/msg00568.html (10,146 bytes)
9. Re: XFS pseudo OOPs. (score: 1): Author: >; Date: Tue, 16 Mar 2004 11:41:23 -0600; I just took a look at the extra lvm patch (v1.0.7) that Axel has added to his AT kernel. It's touching fs/buffer.c and fs/super.c as well as [reiser|ext3]/[buffer.c|super.c] but nothing in the xfs tr; /archives/xfs/2004-03/msg00569.html (11,118 bytes)
10. Re: XFS pseudo OOPs. (score: 1): Author: >; Date: Wed, 17 Mar 2004 16:05:58 +1100; Hmmm.. not sure what patch that is - maybe the VFS locking patch for LVM snapshots? If so, its unlikely to be the cause here. Does that mean you have a reliable failure/test case? If not, could you t; /archives/xfs/2004-03/msg00579.html (8,307 bytes)

Current List: 1 - 10
Page: [1]