xfs open questions

xfs open questions

[Michael Monnerie]

[-- Attachment #1.1: Type: text/plain, Size: 5386 bytes --]

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=0

and 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

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.
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
-- 
// 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


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Eric Sandeen]

Michael Monnerie wrote:
> 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.

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).

> - 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.

> 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

> 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.

> 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.

> - 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.

> - 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.

> 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=0
> 
> and 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
> 
> 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.

> 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 ....

> - 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.

> 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

> mfg zmi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Michael Monnerie]

[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]

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
-- 
// 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


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Russell Cattelan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Monnerie wrote:
> 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.

>
> mfg zmi
>
> ----------------------------------------------------------------------
>
>
> _______________________________________________ xfs mailing list
> xfs@oss.sgi.com 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Michael Monnerie]

[-- Attachment #1.1: Type: text/plain, Size: 4454 bytes --]

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.

> 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!

> > 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?

> 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.

> Hm it's unfortunate that there are no units on that number.  Easy to
> fix.

For who? Are you one of the devs?

> 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.

> 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?

> > - 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?

> 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.

> 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... ;-)

> All good questions, thanks.

:-)

mfg zmi
-- 
// 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


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Michael Monnerie]

[-- Attachment #1.1: Type: text/plain, Size: 733 bytes --]

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
-- 
// 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


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Mark Goodwin]

Michael Monnerie wrote:
> 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.

> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Russell Cattelan]

Michael Monnerie wrote:
> 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.

> mfg zmi
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>   

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Russell Cattelan]

[-- Attachment #1.1: Type: text/plain, Size: 720 bytes --]

Russell Cattelan wrote:
> Michael Monnerie wrote:
>   
>> 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.
>
>
>   
Grr try #2



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Eric Sandeen]

Mark Goodwin wrote:
> 
> Michael Monnerie wrote:
>> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Christoph Hellwig]

On Wed, Jan 28, 2009 at 09:37:19AM +0100, Michael Monnerie wrote:
> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

invalidated gpg signatures (was: Re: xfs open questions)

[Martin Steigerwald]

[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]

Am Mittwoch 28 Januar 2009 schrieb Russell Cattelan:
> Russell Cattelan wrote:
> > Michael Monnerie wrote:
> >> 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.
>
> 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.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: invalidated gpg signatures (was: Re: xfs open questions)

[Iustin Pop]

On Wed, Jan 28, 2009 at 09:22:00PM +0100, Martin Steigerwald wrote:
> Am Mittwoch 28 Januar 2009 schrieb Russell Cattelan:
> > Russell Cattelan wrote:
> > > Michael Monnerie wrote:
> > >> 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.
> >
> > 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 <Martin@Lichtvoll.de>"
gpg:                 aka "Martin Steigerwald <Martin.Steigerwald@Web.de>"
gpg:                 aka "Martin Steigerwald (Helios) <Martin@Lichtvoll.de>"
gpg:                 aka "Martin Steigerwald <Martin.Steigerwald@Googlemail.com>"

So maybe it's not the mailling list itself, but something else?

regards,
iustin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: invalidated gpg signatures (was: Re: xfs open questions)

[Martin Steigerwald]

[-- Attachment #1.1: Type: text/plain, Size: 1954 bytes --]

Am Mittwoch 28 Januar 2009 schrieb Iustin Pop:
> On Wed, Jan 28, 2009 at 09:22:00PM +0100, Martin Steigerwald wrote:
> > Am Mittwoch 28 Januar 2009 schrieb Russell Cattelan:
> > > Russell Cattelan wrote:
> > > > Michael Monnerie wrote:
> > > >> 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.
> > >
> > > 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
> <Martin@Lichtvoll.de>" gpg:                 aka "Martin Steigerwald
> <Martin.Steigerwald@Web.de>" gpg:                 aka "Martin
> Steigerwald (Helios) <Martin@Lichtvoll.de>" gpg:                 aka
> "Martin Steigerwald <Martin.Steigerwald@Googlemail.com>"
>
> 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.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Mark Goodwin]

Eric Sandeen wrote:
> Mark Goodwin wrote:
>> Michael Monnerie wrote:
>>> 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

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 at
git://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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: invalidated gpg signatures (was: Re: xfs open questions)

[Michael Monnerie]

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
-- 
// 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs open questions

[Christoph Hellwig]

On Thu, Jan 29, 2009 at 04:27:03PM +1100, Mark Goodwin wrote:
> doc & ppt binary formats. My first thought was another git repository at
> git://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?

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs