Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*TAKE\s+\-\s+write\s+performance\s+improvement\s*$/: 21 ]

Total 21 documents matching your query.

1. TAKE - write performance improvement (score: 1)
Author: Ananth Ananthanarayanan <ananth@xxxxxxxxxxxxxxxxx>
Date: Mon, 28 Aug 2000 16:16:06 -0700
With this change streaming writes perform almost at the speed of streaming read, as measured with lmdd and bonnie even when 1K & 2K chunks are used for write. The following file(s) were checked into:
/archives/xfs/2000-08/msg00392.html (7,660 bytes)

2. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 08:56:44 -0500
I am backing out this change, it breaks doio, and probably anything else which fills holes in files. I think we had a similar test condition in this code path before, and it was removed to fix corrup
/archives/xfs/2000-08/msg00396.html (8,633 bytes)

3. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 09:14:02 -0500
OK, now I am puzzled, I still got corruption after I backed out the mod, I removed the old doio output file and the corruption went away on subsequent runs and I have not been able to reproduce it w
/archives/xfs/2000-08/msg00397.html (8,346 bytes)

4. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 11:44:37 -0500
I y. Looks like the corruption is once again coming out of the clustering write code in pagebuf, I would recommend not using the kiocluster mount option at the moment. I am doing a glibc build with
/archives/xfs/2000-08/msg00401.html (8,661 bytes)

5. Re: TAKE - write performance improvement (score: 1)
Author: Rajagopal Ananthanarayanan <ananth@xxxxxxx>
Date: Tue, 29 Aug 2000 12:00:01 -0700
Yikes! Sorry if my change caused this problem. But I ran rpmbuild, kernel build and doio (1,2 threads) before checking-in the change ... -- -- Rajagopal Ananthanarayanan ("ananth") Member Technical S
/archives/xfs/2000-08/msg00403.html (9,226 bytes)

6. Re: TAKE - write performance improvement (score: 1)
Author: Jens Axboe <axboe@xxxxxxx>
Date: Wed, 30 Aug 2000 01:10:48 +0200
Aughr, this could explain some weirdness that I'm seeing on IDE kiobuf atm. Basically, kio and "plain" xfs works just fine and I can't crash it. No corruption either. But kiocluster corrupts data her
/archives/xfs/2000-08/msg00417.html (8,770 bytes)

7. Re: TAKE - write performance improvement (score: 1)
Author: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Tue, 29 Aug 2000 18:35:40 -0500
It is unclear at this point where the corruption is coming from there is evidence that it has nothing to do with kiobuf's/ clustering. LVM testing is also showing corruption... it doesn't use kio buf
/archives/xfs/2000-08/msg00419.html (8,934 bytes)

8. TAKE - write performance improvement (score: 1)
Author: Ananth Ananthanarayanan <ananth@xxxxxxxxxxxxxxxxx>
Date: Mon, 28 Aug 2000 16:16:06 -0700
With this change streaming writes perform almost at the speed of streaming read, as measured with lmdd and bonnie even when 1K & 2K chunks are used for write. The following file(s) were checked into:
/archives/xfs/2000-08/msg00859.html (7,660 bytes)

9. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 08:56:44 -0500
I am backing out this change, it breaks doio, and probably anything else which fills holes in files. I think we had a similar test condition in this code path before, and it was removed to fix corrup
/archives/xfs/2000-08/msg00863.html (8,633 bytes)

10. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 09:14:02 -0500
OK, now I am puzzled, I still got corruption after I backed out the mod, I removed the old doio output file and the corruption went away on subsequent runs and I have not been able to reproduce it w
/archives/xfs/2000-08/msg00864.html (8,346 bytes)

11. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 11:44:37 -0500
I y. Looks like the corruption is once again coming out of the clustering write code in pagebuf, I would recommend not using the kiocluster mount option at the moment. I am doing a glibc build with
/archives/xfs/2000-08/msg00868.html (8,661 bytes)

12. Re: TAKE - write performance improvement (score: 1)
Author: Rajagopal Ananthanarayanan <ananth@xxxxxxx>
Date: Tue, 29 Aug 2000 12:00:01 -0700
Yikes! Sorry if my change caused this problem. But I ran rpmbuild, kernel build and doio (1,2 threads) before checking-in the change ... -- -- Rajagopal Ananthanarayanan ("ananth") Member Technical S
/archives/xfs/2000-08/msg00870.html (9,226 bytes)

13. Re: TAKE - write performance improvement (score: 1)
Author: Jens Axboe <axboe@xxxxxxx>
Date: Wed, 30 Aug 2000 01:10:48 +0200
Aughr, this could explain some weirdness that I'm seeing on IDE kiobuf atm. Basically, kio and "plain" xfs works just fine and I can't crash it. No corruption either. But kiocluster corrupts data her
/archives/xfs/2000-08/msg00884.html (8,770 bytes)

14. Re: TAKE - write performance improvement (score: 1)
Author: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Tue, 29 Aug 2000 18:35:40 -0500
It is unclear at this point where the corruption is coming from there is evidence that it has nothing to do with kiobuf's/ clustering. LVM testing is also showing corruption... it doesn't use kio buf
/archives/xfs/2000-08/msg00886.html (8,934 bytes)

15. TAKE - write performance improvement (score: 1)
Author: Ananth Ananthanarayanan <ananth@xxxxxxxxxxxxxxxxx>
Date: Mon, 28 Aug 2000 16:16:06 -0700
With this change streaming writes perform almost at the speed of streaming read, as measured with lmdd and bonnie even when 1K & 2K chunks are used for write. The following file(s) were checked into:
/archives/xfs/2000-08/msg01326.html (7,660 bytes)

16. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 08:56:44 -0500
I am backing out this change, it breaks doio, and probably anything else which fills holes in files. I think we had a similar test condition in this code path before, and it was removed to fix corrup
/archives/xfs/2000-08/msg01330.html (8,703 bytes)

17. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 09:14:02 -0500
OK, now I am puzzled, I still got corruption after I backed out the mod, I removed the old doio output file and the corruption went away on subsequent runs and I have not been able to reproduce it w
/archives/xfs/2000-08/msg01331.html (8,414 bytes)

18. Re: TAKE - write performance improvement (score: 1)
Author: Steve Lord <lord@xxxxxxx>
Date: Tue, 29 Aug 2000 11:44:37 -0500
I y. Looks like the corruption is once again coming out of the clustering write code in pagebuf, I would recommend not using the kiocluster mount option at the moment. I am doing a glibc build with
/archives/xfs/2000-08/msg01335.html (8,729 bytes)

19. Re: TAKE - write performance improvement (score: 1)
Author: Rajagopal Ananthanarayanan <ananth@xxxxxxx>
Date: Tue, 29 Aug 2000 12:00:01 -0700
Yikes! Sorry if my change caused this problem. But I ran rpmbuild, kernel build and doio (1,2 threads) before checking-in the change ... -- -- Rajagopal Ananthanarayanan ("ananth") Member Technical S
/archives/xfs/2000-08/msg01337.html (9,255 bytes)

20. Re: TAKE - write performance improvement (score: 1)
Author: Jens Axboe <axboe@xxxxxxx>
Date: Wed, 30 Aug 2000 01:10:48 +0200
Aughr, this could explain some weirdness that I'm seeing on IDE kiobuf atm. Basically, kio and "plain" xfs works just fine and I can't crash it. No corruption either. But kiocluster corrupts data her
/archives/xfs/2000-08/msg01351.html (8,908 bytes)

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