xfs open questions
Dear list,
I'm new here, experienced admin, trying to understand XFS correctly. I've read
http://xfs.org/index.php/XFS_Status_Updates
http://oss.sgi.com/projects/xfs/training/index.html
http://en.wikipedia.org/wiki/Xfs
and still have some xfs questions, which I guess should be in the FAQ also because they were the first questions I raised when trying XFS. I hope this is the correct list to ask this, and hope this very long first mail isn't too intrusive:
- Stripe Alignment
It's very nice to have the FS understand where it runs on, and that you can optimize for it. But the documentation on how to do that correctly is incomplete.
http://oss.sgi.com/projects/xfs/training/xfs_slides_04_mkfs.pdf
On page 5 is an example an an "8+1 RAID". Does it mean "9 disks in RAID-5"? So 8 are data and 1 is parity, and for XFS only the data disks are important?
If so, when I have a 8 disks RAID 6 (where 2 are parity, 6 data) and a 8 disks RAID-50 (again 2 parity, 6 data) would be the same? Let's say I have 64k stripe size on the RAID controller, with above 8 disks RAID 6. So best performance would be
mkfs -d su=64k,sw=$((64*6))k
is that correct? It would be good if there's clearer documentation with more examples.
- 64bit Inodes
On the allocator's slides
http://oss.sgi.com/projects/xfs/training/xfs_slides_06_allocators.pdf
it's said that if the volume is >1TB, 32bit Inodes make the FS suffer, and that 64bit Inodes should be used. Is that a safe function? Documentation says some backup tools can't handle 64bit Inodes, are there problems with other programs as well? Is the system fully supporting 64bit Inodes? 64bit Linux kernel needed I guess? And if I already created a FS >1TB with 32bit Inodes, it would be better to recreate it with 64bit Inodes and restore all data then?
- Allocation Groups
When I create a XFS with 2TB, and I know it will be growing as we expand the RAID later, how do I optimize the AG's? If I now start with agcount=16, and later expand the RAID +1TB so having 3 instead 2TB, what happens to the agcount? Is it increased, or are existing AGs expanded so you still have 16 AGs? I guess that new AG's are created, but it's nowhere documented.
- mkfs warnings about stripe width multiples For a RAID 5 with 4 disks having 2,4TB on LVM I did:
# mkfs.xfs -f -L oriondata -b size=4096 -d su=65536,sw=3,agcount=40 -i
attr=2 -l lazy-count=1,su=65536 /dev/p3u_data/data1
Warning: AG size is a multiple of stripe width. This can cause
performance problems by aligning all AGs on the same disk. To avoid
this, run mkfs with an AG size that is one stripe unit smaller, for
example 13762544.
meta-data=/dev/p3u_data/data1 isize=256 agcount=40,
agsize=13762560 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=550502400,
imaxpct=5
= sunit=16 swidth=48 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=32768, version=2
= sectsz=512 sunit=16 blks, lazy-
count=1
realtime =none extsz=4096 blocks=0, rtextents=0and so I did it again with
# mkfs.xfs -f -L oriondata -b size=4096 -d
su=65536,sw=3,agsize=13762544b -i attr=2 -l lazy-count=1,su=65536
/dev/p3u_data/data1
meta-data=/dev/p3u_data/data1 isize=256 agcount=40,
agsize=13762544 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=550501760,
imaxpct=5
= sunit=16 swidth=48 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=32768, version=2
= sectsz=512 sunit=16 blks, lazy-
count=1
realtime =none extsz=4096 blocks=0, rtextents=0It would be good if mkfs would correctly says "... run mkfs with an AG size that is one stripe unit smaller, for example 13762544b". The "b" at the end is very important, that cost me a lot of search in the beginning.
Is there a limit on the number of AG's? Theoretical and practical? Is there a guideline how many AGs to use? Depending on CPU cores, or number of parallel users, or spindles, or something else? Page 4 of the mkfs docs (link above) says "too few or too many AG's should be avoided", but what numbers are "few" and "many"?
- PostgreSQL
The PostgreSQL database creates a directory per DB. From the docs I read that this creates all Inodes within the same AG. But wouldn't it be better for performance to have each table on a different AG? This could be manually achieved manually, but I'd like to hear if that's better or not.
Or are there other tweaks to remember when using PostgreSQL on XFS? This question was raised on the PostgreSQL admin list, and if there are good guidelines I'm happy to post them there.
mfg zmi
Signature · 5 lines
// Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 12 lines · Michael Monnerie
Dear list,
I'm new here, experienced admin, trying to understand XFS correctly. I've read
http://xfs.org/index.php/XFS_Status_Updates
http://oss.sgi.com/projects/xfs/training/index.html
http://en.wikipedia.org/wiki/Xfs
and still have some xfs questions, which I guess should be in the FAQ also because they were the first questions I raised when trying XFS. I hope this is the correct list to ask this, and hope this very long first mail isn't too intrusive:
Quoted 15 lines
- Stripe Alignment
It's very nice to have the FS understand where it runs on, and that you can optimize for it. But the documentation on how to do that correctly is incomplete.
http://oss.sgi.com/projects/xfs/training/xfs_slides_04_mkfs.pdf
On page 5 is an example an an "8+1 RAID". Does it mean "9 disks in RAID-5"? So 8 are data and 1 is parity, and for XFS only the data disks are important?
If so, when I have a 8 disks RAID 6 (where 2 are parity, 6 data) and a 8 disks RAID-50 (again 2 parity, 6 data) would be the same? Let's say I have 64k stripe size on the RAID controller, with above 8 disks RAID 6. So best performance would be
mkfs -d su=64k,sw=$((64*6))k
is that correct? It would be good if there's clearer documentation with more examples.
I think that's all correct. It's basically this: stripe unit is per-disk, sripe width is unit*data_disks. And then there's the added bonus of the differing units on su/sw vs. sunit/swidth. :)
I'd love to be able to update these pdf files, but despite asking for the source document several times over a couple months, nothing has been provided. Unfortunately 'til then it's up to SGI to update them and the community can't help much (SGI: hint, hint).
Quoted 5 lines
- 64bit Inodes
On the allocator's slides
http://oss.sgi.com/projects/xfs/training/xfs_slides_06_allocators.pdf
it's said that if the volume is >1TB, 32bit Inodes make the FS suffer, and that 64bit Inodes should be used. Is that a safe function?
It is safe from the filesystem integrity perspective, but as you note below some applications may have trouble.
Quoted 2 lines
Documentation says some backup tools can't handle 64bit Inodes, are there problems with other programs as well?
Potentially, yes:
http://sandeen.net/wordpress/?p=9
Quoted 2 lines
Is the system fully
supporting 64bit Inodes? 64bit Linux kernel needed I guess?
The very latest (2.6.29) kernels can use the inode64 option on a 32-bit machine. And stat64 can be used on a 32bit machine as well, but it's up to apps to do this.
Quoted 2 lines
And if I already created a FS >1TB with 32bit Inodes, it would be better to recreate it with 64bit Inodes and restore all data then?
You can always mount with inode64; your data allocation patterns will be somewhat different. In the first case, your data will be more heavily shifted towards the high blocks of the filesystem, to keep room available for (32-bit) inodes in the lower blocks.
Quoted 7 lines
- Allocation Groups
When I create a XFS with 2TB, and I know it will be growing as we expand the RAID later, how do I optimize the AG's? If I now start with agcount=16, and later expand the RAID +1TB so having 3 instead 2TB, what happens to the agcount? Is it increased, or are existing AGs expanded so you still have 16 AGs? I guess that new AG's are created, but it's nowhere documented.
Yes, growing a filesystem simply fills out the last AG to full size if it's not already, and then adds additional AGs on the end, with a potentially "short" ag on the end, depending on the size.
I would not get overly concerned with AG count; newer mkfs.xfs has lower defaults (i.e. creates larger AGs, 4 by default, even for a 2T filesystem) but to some degree what's "best" depends both on the storage underneath and the way the fs will be used.
But with defaults, your 2T/4AG filesystem case above would grow to 3T/6AGs, which is fine for many cases.
Quoted 8 lines
- mkfs warnings about stripe width multiples For a RAID 5 with 4 disks having 2,4TB on LVM I did:
# mkfs.xfs -f -L oriondata -b size=4096 -d su=65536,sw=3,agcount=40 -i attr=2 -l lazy-count=1,su=65536 /dev/p3u_data/data1 Warning: AG size is a multiple of stripe width. This can cause performance problems by aligning all AGs on the same disk. To avoid this, run mkfs with an AG size that is one stripe unit smaller, for example 13762544.
Hm it's unfortunate that there are no units on that number. Easy to fix.
This is to avoid all metadata landing on a single disk; similar to how mkfs.ext3 wants to use "stride" in its one geometry-tuning knob.
Quoted 28 lines
meta-data=/dev/p3u_data/data1 isize=256 agcount=40,
agsize=13762560 blks= sectsz=512 attr=2 data = bsize=4096 blocks=550502400, imaxpct=5 = sunit=16 swidth=48 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=16 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0and so I did it again with
# mkfs.xfs -f -L oriondata -b size=4096 -d su=65536,sw=3,agsize=13762544b -i attr=2 -l lazy-count=1,su=65536 /dev/p3u_data/data1 meta-data=/dev/p3u_data/data1 isize=256 agcount=40, agsize=13762544 blks = sectsz=512 attr=2 data = bsize=4096 blocks=550501760, imaxpct=5 = sunit=16 swidth=48 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=16 blks, lazy- count=1 realtime =none extsz=4096 blocks=0, rtextents=0
Quoted 4 lines
It would be good if mkfs would correctly says "... run mkfs with an AG size that is one stripe unit smaller, for example
13762544b". The "b" at the end is very important, that cost me a lot of search in the beginning.
Agreed.
Quoted 5 lines
Is there a limit on the number of AG's? Theoretical and practical? Is there a guideline how many AGs to use? Depending on CPU cores, or number of parallel users, or spindles, or something else? Page 4 of the mkfs docs (link above) says "too few or too many AG's should be avoided", but what numbers are "few" and "many"?
:)
The defaults were recently moved to be lower (4 by default). Files in new subdirs are rotated into new AGs, all other things being equal (space available, 64-bit-inode allocator mode). To be honest I don't have a good answer for you on when you'd want more or fewer AGs, although AGs are parallel independent chunks of the fs to large degree, so in some cases, more AGs may help certain kinds of parallel operations. Perhaps others can chime in a bit more on this tuning ....
Quoted 6 lines
- PostgreSQL
The PostgreSQL database creates a directory per DB. From the docs I read that this creates all Inodes within the same AG. But wouldn't it be better for performance to have each table on a different AG? This could be manually achieved manually, but I'd like to hear if that's better or not.
Hm, where in the docs, just to be clear?
All things being equal, new subdirs get their inodes & data in new AGs, and inodes & data for files in that subdir will generally stay in that AG.
[root test]# for I in seq 1 8; do mkdir $I; cp file $I; done [root test]# for I in seq 1 8; do xfs_bmap -v $I/file; done 1/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 96..127 0 (96..127) 32
2/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 256096..256127 1 (96..127) 32
3/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 521696..521727 2 (9696..9727) 32
4/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 768096..768127 3 (96..127) 32
5/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 128..159 0 (128..159) 32
6/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 256128..256159 1 (128..159) 32
7/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 521728..521759 2 (9728..9759) 32
8/file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..31]: 768128..768159 3 (128..159) 32
Note how the AG rotors around my 4 AGs in the filesystem. If the fs is full and aged, it may not behave exactly this way.
Quoted 3 lines
Or are there other tweaks to remember when using PostgreSQL on XFS? This question was raised on the PostgreSQL admin list, and if there are good guidelines I'm happy to post them there.
I don't have specific experience w/ PostgreSQL but if you have specific questions or performance problems that you run into, we can probably help.
All good questions, thanks.
-Eric
Quoted 1 line
mfg zmi
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 3 lines · On Dienstag 27 Januar 2009 Eric Sandeen wrote:
I think that's all correct. It's basically this: stripe unit is per-disk, sripe width is unit*data_disks. And then there's the added bonus of the differing units on su/sw vs. sunit/swidth. :)
Yes, it's always fun to have it complicated.
Quoted 4 lines
I'd love to be able to update these pdf files, but despite asking for the source document several times over a couple months, nothing has been provided. Unfortunately 'til then it's up to SGI to update them and the community can't help much (SGI: hint, hint).
SGI, do you read that? Your users want to do your work, you should be happy 'bout that!
Quoted 5 lines
Quoted 2 lines
Documentation says some backup tools can't handle 64bit Inodes, are there problems with other programs as well?
Potentially, yes:
http://sandeen.net/wordpress/?p=9
OK, so is there anything really problematic? I did already mount with inode64, is there a way back?
Quoted 7 lines
I would not get overly concerned with AG count; newer mkfs.xfs has lower defaults (i.e. creates larger AGs, 4 by default, even for a 2T filesystem) but to some degree what's "best" depends both on the storage underneath and the way the fs will be used.
But with defaults, your 2T/4AG filesystem case above would grow to 3T/6AGs, which is fine for many cases.
I used 40 AG's, so it will be 60 then.
Quoted 2 lines
Hm it's unfortunate that there are no units on that number. Easy to fix.
For who? Are you one of the devs?
Quoted 2 lines
This is to avoid all metadata landing on a single disk; similar to how mkfs.ext3 wants to use "stride" in its one geometry-tuning knob.
I find the concept good, just the doc about it should be better/clearer. And why didn't they choose to specify # of disks, swidth has to be a multiple of sunit anyway? With su=65536,sw=3 it's at least clearer.
Quoted 7 lines
The defaults were recently moved to be lower (4 by default). Files in new subdirs are rotated into new AGs, all other things being equal (space available, 64-bit-inode allocator mode). To be honest I don't have a good answer for you on when you'd want more or fewer AGs, although AGs are parallel independent chunks of the fs to large degree, so in some cases, more AGs may help certain kinds of parallel operations. Perhaps others can chime in a bit more on this tuning
Nobody?
Quoted 8 lines
Quoted 6 lines
- PostgreSQL
The PostgreSQL database creates a directory per DB. From the docs I read that this creates all Inodes within the same AG. But wouldn't it be better for performance to have each table on a different AG? This could be manually achieved manually, but I'd like to hear if that's better or not.Hm, where in the docs, just to be clear?
I meant the XFS docs - you said it again "files in the same dir are kept in the same AG". I wasn't clear enough on that. PostgreSQL creates a new DB in a new dir, but all tables etc. are just new files within that dir, which is probably not exactly what one wants. I can imagine it helps to stop the DB, "cp" all files to an extra dir once, to get them distributed over the AG's, and then "mv" them back so just the dir entry is moved but the files stays at that other AG. Or does that sound silly?
Quoted 2 lines
Note how the AG rotors around my 4 AGs in the filesystem. If the fs is full and aged, it may not behave exactly this way.
Does anybody have experience with an aged XFS? I've had the problem with reiserfs, that it became slow after a certain point. It took ages to search within a directory of MP3's containing 50.000 entries in many directories.
Quoted 3 lines
I don't have specific experience w/ PostgreSQL but if you have specific questions or performance problems that you run into, we can probably help.
Just the idea from above, to cp & mv all files once after creating to distribute among AG's. There was just a general discussion whether XFS is good for postgres or not. Could have been there's that "super-trick" to speed up things by a factor of 1000... ;-)
Quoted 1 line
All good questions, thanks.
:-)
mfg zmi
Signature · 5 lines
// Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Michael Monnerie
Quoted 4 lines · On Dienstag 27 Januar 2009 Eric Sandeen wrote:
I'd love to be able to update these pdf files, but despite asking for the source document several times over a couple months, nothing has been provided. Unfortunately 'til then it's up to SGI to update them and the community can't help much (SGI: hint, hint).
it's (finally) on the Open Source Review Board meeting agenda for tomorrow (6am in my TZ :) I expect to release the src docs shortly after that; the oss release process is time consuming.
Quoted 2 lines
SGI, do you read that? Your users want to do your work, you should be happy 'bout that!
yes certainly, thanks.
Cheers
-- Mark
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 11 lines · Mark Goodwin
Quoted 5 lines · Michael Monnerie
Quoted 4 lines · On Dienstag 27 Januar 2009 Eric Sandeen wrote:
I'd love to be able to update these pdf files, but despite asking for the source document several times over a couple months, nothing has been provided. Unfortunately 'til then it's up to SGI to update them and the community can't help much (SGI: hint, hint).
it's (finally) on the Open Source Review Board meeting agenda for tomorrow (6am in my TZ :) I expect to release the src docs shortly after that; the oss release process is time consuming.
Thanks for the update Mark, that's good news. Sorry for being snippy. I do know how these things go... ;)
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Eric Sandeen
Quoted 6 lines · Mark Goodwin
Quoted 5 lines · Michael Monnerie
Quoted 4 lines · On Dienstag 27 Januar 2009 Eric Sandeen wrote:
I'd love to be able to update these pdf files, but despite asking for the source document several times over a couple months, nothing has been provided. Unfortunately 'til then it's up to SGI to update them and the community can't help much (SGI: hint, hint).
Quoted 8 lines
Quoted 3 lines
it's (finally) on the Open Source Review Board meeting agenda for tomorrow (6am in my TZ :) I expect to release the src docs shortly after that; the oss release process is time consuming.
Thanks for the update Mark, that's good news. Sorry for being snippy. I do know how these things go... ;)
-Eric
well it's now been approved for release under the GNU FDL to be hosted on oss.sgi.com. I guess one question now is how to deal with the proprietary doc & ppt binary formats. My first thought was another git repository atgit://oss/xfs/cmds/xfsdocs.git which would also include the web site html content. But doc and ppt binary files apparently always result in git merge conflicts (can't be patched) ... thoughts? Perhaps convert the content to wiki or maybe html and manage changes that way?
Cheers
-- Mark
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Mark Goodwin
doc & ppt binary formats. My first thought was another git repository at
git://oss/xfs/cmds/xfsdocs.gitwhich would also include the web site html content. But doc and ppt binary files apparently always result in git merge conflicts (can't be patched) ... thoughts? Perhaps convert the content to wiki or maybe html and manage changes that way?
Better a git with merge conflicts than no SCM at all. So let's get it out and into the new xfsdocs.git repo ASAP, and we'll see if we can convert it to a more open format later.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Michael Monnerie
SGI, do you read that? Your users want to do your work, you should be happy 'bout that!
While Eric also is a user of XFS he's more importantly one of the most active developers currently..
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 1 line · On Dienstag 27 Januar 2009 Michael Monnerie wrote:
Dear list,
Oh, as a side note: I see that my gpg signature gets broken on this mailing list. Could the admin (who's that?) please fix that? I can't see what exactly causes the gpg sig to be broken.
mfg zmi
Signature · 5 lines
// Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 6 lines · Michael Monnerie
Quoted 1 line · On Dienstag 27 Januar 2009 Michael Monnerie wrote:
Dear list,
Oh, as a side note: I see that my gpg signature gets broken on this
mailing list. Could the admin (who's that?) please fix that? I
can't see what exactly causes th?e gpg sig to be broken.
The sig is there, are you saying it's broken somehow?
It might have something to do with the html stripper.
Quoted 8 lines
mfg zmi
----------------------------------------------------------------------
_______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJf9wWNRmM+OaGhBgRAm5RAJ4uoaFDZ2ou5RnyXrRnSksPNyFEtgCfcSe3 hX47xQVFrdz6vtEDaBo8Vlk=
=WICw
-----END PGP SIGNATURE-----
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · On Mittwoch 28 Januar 2009 Russell Cattelan wrote:
The sig is there, are you saying it's broken somehow? It might have something to do with the html stripper.
Yes, I use kmail (from KDE) which automatically displays mails with gpg- sigs in different colours to easily see if it's correct/trusted/wrong. And on this list, my messages all come with "Invalid Sig".
mfg zmi
Signature · 5 lines
// Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Michael Monnerie
Quoted 3 lines · On Mittwoch 28 Januar 2009 Russell Cattelan wrote:
The sig is there, are you saying it's broken somehow? It might have something to do with the html stripper.
Yes, I use kmail (from KDE) which automatically displays mails with gpg- sigs in different colours to easily see if it's correct/trusted/wrong. And on this list, my messages all come with "Invalid Sig".
Well I ran a test email through the test list on oss and it seems to work fine.
Let try it here then, I'm going to sign this and see if it come back to me with
a valid sig.
Quoted 9 lines
mfg zmi
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 15 lines · Russell Cattelan
Quoted 12 lines · Michael Monnerie
Quoted 4 lines · On Mittwoch 28 Januar 2009 Russell Cattelan wrote:
The sig is there, are you saying it's broken somehow? It might have something to do with the html stripper.
Yes, I use kmail (from KDE) which automatically displays mails with gpg- sigs in different colours to easily see if it's correct/trusted/wrong. And on this list, my messages all come with "Invalid Sig".
Quoted 8 lines
Well I ran a test email through the test list on oss and it seems to work fine.
Let try it here then, I'm going to sign this and see if it come back to me with a valid sig.
Grr try #2
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
invalidated gpg signatures (was: Re: xfs open questions)
Am Mittwoch 28 Januar 2009 schrieb Russell Cattelan:
Quoted 11 lines
Quoted 10 lines · Russell Cattelan
Quoted 8 lines · Michael Monnerie
Quoted 2 lines · On Mittwoch 28 Januar 2009 Russell Cattelan wrote:
The sig is there, are you saying it's broken somehow? It might have something to do with the html stripper.
Yes, I use kmail (from KDE) which automatically displays mails with gpg- sigs in different colours to easily see if it's correct/trusted/wrong. And on this list, my messages all come with "Invalid Sig".
Quoted 7 lines
Quoted 5 lines
Well I ran a test email through the test list on oss and it seems to work fine.
Let try it here then, I'm going to sign this and see if it come back to me with a valid sig.
Grr try #2
Shown as invalid here - as the signature of Michael. I mentioned this a few times already to.
Signing this as well, but I expect it will come out as invalid too.
I think it can't be Mailman. As I am on several Mailman mailinglist where this works.
Signature · 2 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: invalidated gpg signatures (was: Re: xfs open questions)
Quoted 18 lines · Martin Steigerwald
Am Mittwoch 28 Januar 2009 schrieb Russell Cattelan:
Quoted 17 lines
Quoted 15 lines · Russell Cattelan
Quoted 8 lines · Michael Monnerie
Quoted 2 lines · On Mittwoch 28 Januar 2009 Russell Cattelan wrote:
The sig is there, are you saying it's broken somehow? It might have something to do with the html stripper.
Yes, I use kmail (from KDE) which automatically displays mails with gpg- sigs in different colours to easily see if it's correct/trusted/wrong. And on this list, my messages all come with "Invalid Sig".
Well I ran a test email through the test list on oss and it seems to work fine.
Let try it here then, I'm going to sign this and see if it come back to me with a valid sig.
Quoted 6 lines
Quoted 1 line
Grr try #2
Shown as invalid here - as the signature of Michael. I mentioned this a few times already to.
Signing this as well, but I expect it will come out as invalid too.
For what is worth, gpg tells me on your email:
gpg: Signature made Wed 28 Jan 2009 09:22:00 PM CET using DSA key ID A59984C7 gpg: Good signature from "Martin Steigerwald <[email protected]>" gpg: aka "Martin Steigerwald <[email protected]>" gpg: aka "Martin Steigerwald (Helios) <[email protected]>" gpg: aka "Martin Steigerwald <[email protected]>"
So maybe it's not the mailling list itself, but something else?
regards,
iustin
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: invalidated gpg signatures (was: Re: xfs open questions)
Am Mittwoch 28 Januar 2009 schrieb Iustin Pop:
Quoted 28 lines · Martin Steigerwald
Quoted 18 lines
Am Mittwoch 28 Januar 2009 schrieb Russell Cattelan:
Quoted 17 lines
Quoted 15 lines · Russell Cattelan
Quoted 8 lines · Michael Monnerie
Quoted 2 lines · On Mittwoch 28 Januar 2009 Russell Cattelan wrote:
The sig is there, are you saying it's broken somehow? It might have something to do with the html stripper.
Yes, I use kmail (from KDE) which automatically displays mails with gpg- sigs in different colours to easily see if it's correct/trusted/wrong. And on this list, my messages all come with "Invalid Sig".
Well I ran a test email through the test list on oss and it seems to work fine.
Let try it here then, I'm going to sign this and see if it come back to me with a valid sig.
Quoted 6 lines
Quoted 1 line
Grr try #2
Shown as invalid here - as the signature of Michael. I mentioned this a few times already to.
Signing this as well, but I expect it will come out as invalid too.
For what is worth, gpg tells me on your email:
Quoted 8 lines
gpg: Signature made Wed 28 Jan 2009 09:22:00 PM CET using DSA key ID A59984C7 gpg: Good signature from "Martin Steigerwald
<[email protected]>" gpg: aka "Martin Steigerwald
<[email protected]>" gpg: aka "Martin
Steigerwald (Helios) <[email protected]>" gpg: aka
"Martin Steigerwald <[email protected]>"So maybe it's not the mailling list itself, but something else?
Strange. A bug in KMail with decoding GPG signaturesin *some* mails? However I did find this only on the XFS mailing list so far. If I find time I will take a closer look tomorrow.
Signature · 2 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: invalidated gpg signatures (was: Re: xfs open questions)
Quoted 3 lines · On Mittwoch 28 Januar 2009 Martin Steigerwald wrote:
Strange. A bug in KMail with decoding GPG signaturesin *some* mails? However I did find this only on the XFS mailing list so far. If I find time I will take a closer look tomorrow.
Yes, I am in a lot of mailing lists, but only here I see "invalid" sigs.
Russell: Your 1st mail with sig was valid, the 2nd not. Maybe Martin can find the culprit.
mfg zmi
Signature · 10 lines
// Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs