nagging about the LVM usage survey
A message that is not in the archive (sent off-list or not yet received): [email protected]
I believe that Matt meant LVM 1.0 and GFS 5.0
Quoted 1 line · [email protected] said:
Why 5.0?
---
Michael Declerck, [email protected] +1.510.823.7991
Quoted 1 line · Michael J. Declerck
I believe that Matt meant LVM 1.0 and GFS 5.0
Yes, I am sure.
Quoted 13 lines
Quoted 1 line · [email protected] said:
Why 5.0?
---
Michael Declerck, [email protected] +1.510.823.7991_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
Signature · 12 lines
Regards,
Heinz -- The LVM Guy --
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Re: XFS to main kernel source
In reply to a message not in the archiveQuoted 7 lines · Steve Lord
Quoted 2 lines
Since we have your attention - which chunks? One of the frustrations we hav
e
Quoted 1 line
had is the lack of feedback from anyone who has looked at XFS.
o The whole vnode layer
Two answers here - economics and code stability. This is a filesystem which has been worked on by people being payed to do so by a corporation, therefore there is a budget (long since blown). It was simpler and hence cheaper to wrap XFS in a conversion layer than to rework the code down into the bowels of the filesystem. Then the stability part of it, we started with a working filesystem, from an engineering standpoint it made more sense to keep as much of the existing code base intact as possible - the less surgery performed the better in terms of keeping things running, and making it easy to take enhancements and fixes made in the Irix base into the Linux code (we don't do it the other way around).
Quoted 2 lines
o checks already peformed by the VFS all over the place (just take a look at
xfs_rename.c!)
I think I will answer this one more slowly and in response to Al Viro's email. But that economics/stability thing comes into it again.
Quoted 1 line
o the own quoata code
XFS quotas are transactional, when space is added to a file the quota is adjusted in the same transaction. It is fairly hard to do this without your own quota code.
Quoted 1 line
o the hooks for a propritary clusterfs..
Well we have to make money on something you know.... and in reality there are not a lot of them in the filesystem.
Thanks
Steve
Quoted 7 lines
My 2 (euro-)cents,
Christoph
Signature · 1 line
Of course it doesn't work. We've performed a software upgrade.
Re: XFS to main kernel source
Quoted 12 lines · Steve Lord
Quoted 1 line
o The whole vnode layer
Two answers here - economics and code stability. This is a filesystem which has been worked on by people being payed to do so by a corporation, therefore there is a budget (long since blown). It was simpler and hence cheaper to wrap XFS in a conversion layer than to rework the code down into the bowels of the filesystem. Then the stability part of it, we started with a working filesystem, from an engineering standpoint it made more sense to keep as much of the existing code base intact as possible - the less surgery performed the better in terms of keeping things running, and making it easy to take enhancements and fixes made in the Irix base into the Linux code (we don't do it the other way around).
I completly understand SGI's reson to do this - but yet I don't want to see such code in the mainline for obvios reasons..
Quoted 4 lines
Quoted 1 line
o the hooks for a propritary clusterfs..
Well we have to make money on something you know.... and in reality there are not a lot of them in the filesystem.
Again I understand SGI's reasoning - but such hooks are usually not considered to be a good thing line.
Christoph
Signature · 1 line
Of course it doesn't work. We've performed a software upgrade.
Re: XFS to main kernel source
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Oh guys I did not think that this is so "technically impossible". It's good for me to be informed what phylosofical differences you have between SGI and Linux programming style.
If the merge will not happen in around a half year - I think SGI/XFS "will lose market share". And Ext3 is gonna get more of the pie as that is (maybe) possible to patch in the kernel.
I really hope, that there will be a nice technical solution to this issue and there will be no political decisions over technical.
Thanks
- -------------------------
Narancs v1
IT Security Administrator
"Security of information is an illusion.
What is in one's mind gets into the collective consciousness (akasha), so that can be read with meditation ;-) You don't have to hack. Just 'remember'! You're the one."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjuq/PUACgkQGp+ylEhMCIV0tQCeLKOrR4z1QZLWugIiA8hDZM7t TQQAn0fD6QhhtuvNYUZB/si5CQa/XtaE
=k0Lx
-----END PGP SIGNATURE-----
Re: XFS to main kernel source
In reply to Steve LordQuoted 10 lines · Steve Lord
Two answers here - economics and code stability. This is a filesystem which has been worked on by people being payed to do so by a corporation, therefore there is a budget (long since blown). It was simpler and hence cheaper to wrap XFS in a conversion layer than to rework the code down into the bowels of the filesystem. Then the stability part of it, we started with a working filesystem, from an engineering standpoint it made more sense to keep as much of the existing code base intact as possible - the less surgery performed the better in terms of keeping things running, and making it easy to take enhancements and fixes made in the Irix base into the Linux code (we don't do it the other way around).
True, but there's a cost of maintaining the source and reducing the size of said source by order of magnitude will help to reduce _that_.
The argument would make sense if you were treating everything under your compatibility layer as a black box, but I sincerely hope that it's not the case.
Quoted 5 lines
Quoted 2 lines
o checks already peformed by the VFS all over the place (just take a look at
xfs_rename.c!)I think I will answer this one more slowly and in response to Al Viro's email. But that economics/stability thing comes into it again.
Looking forward to that... Just documenting the exclusion requirements of CXFS would help. Big way. As it is, you are bordering on the "adding undocumented API for proprietory module" and while I've got no problems with the last part (I don't suffer from stallmanellosis), I really don't like the first one. Nobody's asking to give up the guts of CXFS, but having its exclusion requirements documented is a different story.
Re: XFS to main kernel source
Quoted 15 lines · Steve Lord
Quoted 11 lines
Two answers here - economics and code stability. This is a filesystem which has been worked on by people being payed to do so by a corporation, therefore there is a budget (long since blown). It was simpler and hence cheaper to wrap XFS in a conversion layer than to rework the code down into the bowels of the filesystem. Then the stability part of it, we started with a working filesystem, from an engineering standpoint it made more sense to keep as much of the existing code base intact as possible - the less surgery performed the better in terms of keeping things running, and making it easy to take enhancements and fixes made in the Irix base into the Linux code (we don't do it the other way around).
Quoted 2 lines
True, but there's a cost of maintaining the source and reducing the size of said source by order of magnitude will help to reduce _that_.
Well there is not an order of magnitude in it, and it then leaves SGI in the situation of having two even more divergent versions of XFS than we have now. I do realise there are two conflicting goals in all of this.
Quoted 4 lines
The argument would make sense if you were treating everything under your compatibility layer as a black box, but I sincerely hope that it's not the case.
Well, not everything, but the vast majority of the xfs code has not had to change at all, we have a different buffer cache interface, and the read/write path is different, and the inode creation/teardown interface needed surgery to work with linux inodes, oh and endian conversion. But apart from that ......
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
o checks already peformed by the VFS all over the place (just take a look at
xfs_rename.c!)I think I will answer this one more slowly and in response to Al Viro's email. But that economics/stability thing comes into it again.
Quoted 6 lines
Looking forward to that... Just documenting the exclusion requirements of CXFS would help. Big way. As it is, you are bordering on the "adding undocumented API for proprietory module" and while I've got no problems with the last part (I don't suffer from stallmanellosis), I really don't like the first one. Nobody's asking to give up the guts of CXFS, but having its exclusion requirements documented is a different story.
Working on the locking first, the tricky part is how locks interact with the transaction mechanism.
Steve
Re: XFS to main kernel source
In reply to a message not in the archiveQuoted 3 lines · Steve Lord
XFS quotas are transactional, when space is added to a file the quota is adjusted in the same transaction. It is fairly hard to do this without your own quota code.
Actually not. The quotas in ext3 are transactional as well. It's just that the "ext3" journal layer allows nested transactions, so it is possible to start a write transaction, call into the journal code which calls back into the ext3 write code to start a nested transaction on the journal file (i.e. it is in the same transaction as the initial write), and then the initial write completes.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Re: [PATCH] Remove needless BKL from release functions
In reply to a message not in the archiveQuoted 4 lines · Horst von Brand
Quoted 2 lines
Nope, it's fine to remove it. Input is racy all over the place and the list are modified somewhere else without any locking anyways.
"It is broken anyway, breaking it some more makes no difference"!?
Wether you lock access to shared data at one or zero points doesn't matter, so it's not breaking it more.
Christoph
Signature · 1 line
Of course it doesn't work. We've performed a software upgrade.