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

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*alpha\s+again\s*$/: 22 ]

Total 22 documents matching your query.

1. alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 24 Nov 2000 18:50:32 GMT; just another try ... maybe someone has an idea now :-) root@cyan:/usr/src/xfs/linux# mkfs -t xfs -f -b size=8192 /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=8, agsize=4142 blks data = bsize=8192; /archives/xfs/2000-11/msg00172.html (10,098 bytes)
2. Re: alpha again (score: 1): Author: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Sun, 26 Nov 2000 13:53:10 -0400; what does "xfs_db -r -c agf -c p /dev/sdb1" say at each point (*) below. (*) here (*) here and (*) here. (could you send me the output in each place - thanks). I'm a little surprised that we can get; /archives/xfs/2000-11/msg00188.html (10,655 bytes)
3. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 27 Nov 2000 08:09:59 GMT; root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1 magicnum = 0x58414746 versionnum = 1 seqno = 0 length = 4142 bnoroot = 1 cntroot = 2 bnolevel = 1 cntlevel = 1 flfirst = 0 fllast = 3 flcount = 4 freeblks; /archives/xfs/2000-11/msg00192.html (12,590 bytes)
4. Re: alpha again (score: 1): Author: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Tue, 28 Nov 2000 09:10:54 -0400; hi Thomas, everything looks good up till here... heh - thats completely bogus. so the problem is in the kernel (xfs mount/umount code paths) after all. on the plus side, mkfs and repair both seem to; /archives/xfs/2000-11/msg00196.html (10,703 bytes)
5. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 28 Nov 2000 10:25:56 GMT; ... ... root@cyan:~# mkfs -t xfs -f -b size=8192 /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=8, agsize=4142 blks data = bsize=8192 blocks=33130, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 na; /archives/xfs/2000-11/msg00202.html (12,870 bytes)
6. Re: alpha again (score: 1): Author: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Thu, 30 Nov 2000 09:16:46 -0400; ok, i've read through the umount code and have a theory. (debugging by proxy is fun!) ;-) is there any chance that the device block size is being set back to 1024 at the end of the umount? i.e. at t; /archives/xfs/2000-11/msg00209.html (11,989 bytes)
7. Re: alpha again (score: 1): Author: Russell Cattelan <cattelan@xxxxxxxxxxx>; Date: Wed, 29 Nov 2000 17:34:12 -0600; Hmm I doubt it, linvfs_put_super through a series of vfs calls fs_dounmount -> xfs_unmount calls XFS_bdflush, aka pagebuf_delwri_flush which should force out any pending meta data buffers. A few SYNC; /archives/xfs/2000-11/msg00212.html (13,781 bytes)
8. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 30 Nov 2000 08:54:00 GMT; root@cyan:~# mkfs -t xfs -f -b size=8192 /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=8, agsize=4142 blks data = bsize=8192 blocks=33130, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =ve; /archives/xfs/2000-11/msg00215.html (12,522 bytes)
9. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 30 Nov 2000 08:56:31 GMT; i will wait with this - because due to russels post it seems to happen earlier and not really on umount just for my understanding: it will only be seen on umount because the trashed blocks will only; /archives/xfs/2000-11/msg00216.html (12,329 bytes)
10. Re: alpha again (score: 1): Author: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Thu, 30 Nov 2000 20:31:59 -0400; yup, that blew my theory out of the water. Russells point was it isn't only seen on unmount though - thats just when we happened to look previously - and we weren't doing anything inbetween mount & u; /archives/xfs/2000-11/msg00218.html (9,730 bytes)
11. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 30 Nov 2000 10:04:06 GMT; maybe this helps a bit more: i was now able to reproduce it also before umount - it takes quite a lot of stuff to copy onto the fs before i see the first corruption with xfs_db but i can see it now b; /archives/xfs/2000-11/msg00219.html (11,004 bytes)
12. alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 24 Nov 2000 18:50:32 GMT; just another try ... maybe someone has an idea now :-) root@cyan:/usr/src/xfs/linux# mkfs -t xfs -f -b size=8192 /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=8, agsize=4142 blks data = bsize=8192; /archives/xfs/2000-11/msg00417.html (10,098 bytes)
13. Re: alpha again (score: 1): Author: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Sun, 26 Nov 2000 13:53:10 -0400; what does "xfs_db -r -c agf -c p /dev/sdb1" say at each point (*) below. (*) here (*) here and (*) here. (could you send me the output in each place - thanks). I'm a little surprised that we can get; /archives/xfs/2000-11/msg00433.html (10,655 bytes)
14. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 27 Nov 2000 08:09:59 GMT; root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1 magicnum = 0x58414746 versionnum = 1 seqno = 0 length = 4142 bnoroot = 1 cntroot = 2 bnolevel = 1 cntlevel = 1 flfirst = 0 fllast = 3 flcount = 4 freeblks; /archives/xfs/2000-11/msg00437.html (12,590 bytes)
15. Re: alpha again (score: 1): Author: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Tue, 28 Nov 2000 09:10:54 -0400; hi Thomas, everything looks good up till here... heh - thats completely bogus. so the problem is in the kernel (xfs mount/umount code paths) after all. on the plus side, mkfs and repair both seem to; /archives/xfs/2000-11/msg00441.html (10,703 bytes)
16. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 28 Nov 2000 10:25:56 GMT; ... ... root@cyan:~# mkfs -t xfs -f -b size=8192 /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=8, agsize=4142 blks data = bsize=8192 blocks=33130, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 na; /archives/xfs/2000-11/msg00447.html (12,870 bytes)
17. Re: alpha again (score: 1): Author: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Thu, 30 Nov 2000 09:16:46 -0400; ok, i've read through the umount code and have a theory. (debugging by proxy is fun!) ;-) is there any chance that the device block size is being set back to 1024 at the end of the umount? i.e. at t; /archives/xfs/2000-11/msg00454.html (11,989 bytes)
18. Re: alpha again (score: 1): Author: Russell Cattelan <cattelan@xxxxxxxxxxx>; Date: Wed, 29 Nov 2000 17:34:12 -0600; Hmm I doubt it, linvfs_put_super through a series of vfs calls fs_dounmount -> xfs_unmount calls XFS_bdflush, aka pagebuf_delwri_flush which should force out any pending meta data buffers. A few SYNC; /archives/xfs/2000-11/msg00457.html (13,781 bytes)
19. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 30 Nov 2000 08:54:00 GMT; root@cyan:~# mkfs -t xfs -f -b size=8192 /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=8, agsize=4142 blks data = bsize=8192 blocks=33130, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =ve; /archives/xfs/2000-11/msg00460.html (12,522 bytes)
20. Re: alpha again (score: 1): Author: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>; Date: 30 Nov 2000 08:56:31 GMT; i will wait with this - because due to russels post it seems to happen earlier and not really on umount just for my understanding: it will only be seen on umount because the trashed blocks will only; /archives/xfs/2000-11/msg00461.html (12,329 bytes)

Current List: 1 - 20
Page: [1] [2]