Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*TAKE\s+\-\s+improve\s+xfs\s+metadata\s+hashing\s*$/: 15 ]

Total 15 documents matching your query.

1. TAKE - improve xfs metadata hashing (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Fri, 14 Feb 2003 16:25:20 -0600
Under heavy load, there are not enough hash buckets to deal with the number of metadata buffers. Use the same techniques as the regular linux buffer cache here. use more hash buckets for holding xfs
/archives/xfs/2003-02/msg00205.html (7,549 bytes)

2. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Fri, 14 Feb 2003 23:43:01 +0100
Hi, I cannot review the change because it hasn't reached the public CVS server yet. But in general I would be very careful with existing hash functions in Linux. Lots of them are suffering from the
/archives/xfs/2003-02/msg00206.html (8,329 bytes)

3. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: 14 Feb 2003 16:49:14 -0600
Well, this one was actually better than the existing one - as measured by a profiler while running spec. But yes, it definitely needs to be capped. I did put an upper ceiling on the size, probably st
/archives/xfs/2003-02/msg00207.html (9,415 bytes)

4. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Sat, 15 Feb 2003 00:15:28 +0100
See http://www.citi.umich.edu/projects/linux-scalability/reports/hash.html for more details. It also gives some suggestions on how to improve it. I think Linux still uses the hash functions criticize
/archives/xfs/2003-02/msg00208.html (9,823 bytes)

5. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Stephen Lord <lord@xxxxxxx>
Date: 17 Feb 2003 08:56:06 -0600
... It turns out there is a bug in this code, and it will trash your filesystem. Fix coming shortly, if you are following cvs, please make sure you update again before using the filesystem. Nothing w
/archives/xfs/2003-02/msg00227.html (8,075 bytes)

6. TAKE - improve xfs metadata hashing (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Fri, 14 Feb 2003 16:25:20 -0600
Under heavy load, there are not enough hash buckets to deal with the number of metadata buffers. Use the same techniques as the regular linux buffer cache here. use more hash buckets for holding xfs
/archives/xfs/2003-02/msg00689.html (7,549 bytes)

7. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Fri, 14 Feb 2003 23:43:01 +0100
Hi, I cannot review the change because it hasn't reached the public CVS server yet. But in general I would be very careful with existing hash functions in Linux. Lots of them are suffering from the
/archives/xfs/2003-02/msg00690.html (8,329 bytes)

8. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: 14 Feb 2003 16:49:14 -0600
Well, this one was actually better than the existing one - as measured by a profiler while running spec. But yes, it definitely needs to be capped. I did put an upper ceiling on the size, probably st
/archives/xfs/2003-02/msg00691.html (9,415 bytes)

9. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Sat, 15 Feb 2003 00:15:28 +0100
See http://www.citi.umich.edu/projects/linux-scalability/reports/hash.html for more details. It also gives some suggestions on how to improve it. I think Linux still uses the hash functions criticize
/archives/xfs/2003-02/msg00692.html (9,823 bytes)

10. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Stephen Lord <lord@xxxxxxx>
Date: 17 Feb 2003 08:56:06 -0600
... It turns out there is a bug in this code, and it will trash your filesystem. Fix coming shortly, if you are following cvs, please make sure you update again before using the filesystem. Nothing w
/archives/xfs/2003-02/msg00711.html (8,075 bytes)

11. TAKE - improve xfs metadata hashing (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Fri, 14 Feb 2003 16:25:20 -0600
Under heavy load, there are not enough hash buckets to deal with the number of metadata buffers. Use the same techniques as the regular linux buffer cache here. use more hash buckets for holding xfs
/archives/xfs/2003-02/msg01173.html (7,549 bytes)

12. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Fri, 14 Feb 2003 23:43:01 +0100
Hi, I cannot review the change because it hasn't reached the public CVS server yet. But in general I would be very careful with existing hash functions in Linux. Lots of them are suffering from the
/archives/xfs/2003-02/msg01174.html (8,395 bytes)

13. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: 14 Feb 2003 16:49:14 -0600
Well, this one was actually better than the existing one - as measured by a profiler while running spec. But yes, it definitely needs to be capped. I did put an upper ceiling on the size, probably st
/archives/xfs/2003-02/msg01175.html (9,508 bytes)

14. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Sat, 15 Feb 2003 00:15:28 +0100
See http://www.citi.umich.edu/projects/linux-scalability/reports/hash.html for more details. It also gives some suggestions on how to improve it. I think Linux still uses the hash functions criticize
/archives/xfs/2003-02/msg01176.html (9,967 bytes)

15. Re: TAKE - improve xfs metadata hashing (score: 1)
Author: Stephen Lord <lord@xxxxxxx>
Date: 17 Feb 2003 08:56:06 -0600
... It turns out there is a bug in this code, and it will trash your filesystem. Fix coming shortly, if you are following cvs, please make sure you update again before using the filesystem. Nothing w
/archives/xfs/2003-02/msg01195.html (8,204 bytes)

Current List: 1 - 15
Page: [1]
This search system is powered by Namazu