Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+disable\s+queue\s+flag\s+test\s+in\s+barrier\s+check\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+disable\s+queue\s+flag\s+test\s+in\s+barrier\s+check\s*$/: 21 ]

Total 21 documents matching your query.

1. [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Wed, 25 Jun 2008 22:07:22 -0500; md raid1 can pass down barriers, but does not set an ordered flag on the queue, so xfs does not even attempt a barrier write, and will never use barriers on these block devices. I propose removing th; /archives/xfs/2008-06/msg00329.html (9,159 bytes)
2. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Timothy Shimmin <tes@xxxxxxx>; Date: Thu, 26 Jun 2008 18:25:40 +1000; Yeah, okay so we are revisiting this stuff again. Fair enough. (Groan;-) So it was brought to our attention by Neil a while ago: 1. Looking back, we agreed at the time that this seemed reasonable. (s; /archives/xfs/2008-06/msg00349.html (19,380 bytes)
3. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Thu, 26 Jun 2008 08:25:11 -0500; But that's an admin issue. The way it is now, for example a home user of md raid1 (me!) can't run barriers even if they wanted to. Until there is a way to know if a write cache is non-volatile the on; /archives/xfs/2008-06/msg00367.html (10,475 bytes)
4. RE: [PATCH] disable queue flag test in barrier check (score: 1): Author: "David Lethe" <david@xxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 09:47:19 -0500; Not sure what you mean about non-volatile vs. volatile write cache, however. If you want to see if write cache is enabled on a disk drive, or Even a logical disk on a hardware-based RAId, under Linux; /archives/xfs/2008-06/msg00368.html (12,263 bytes)
5. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Thu, 26 Jun 2008 09:57:18 -0500; I'm not so interested in whether it is enabled; I'd like to know if it is safe (to varying degrees) in the event of a power failure, and I don't think there's any way we can know that. So the adminis; /archives/xfs/2008-06/msg00369.html (10,011 bytes)
6. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: "David Lethe" <david@xxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 10:24:00 -0500; Unflushed writes are 100% effective for losing data and corrupting file systems. Data isn't saved until it is on the magnetic media. Batterybackup modules for disk controllers help, but there is no s; /archives/xfs/2008-06/msg00370.html (10,898 bytes)
7. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Timothy Shimmin <tes@xxxxxxx>; Date: Fri, 27 Jun 2008 14:51:41 +1000; I understand what you are saying. I agree. And I agreed when it went out last time. But as it has: <- gone out I want to make sure that everyone is happy for it to go back out again. (Cut the string; /archives/xfs/2008-06/msg00389.html (11,144 bytes)
8. [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Wed, 25 Jun 2008 22:07:22 -0500; md raid1 can pass down barriers, but does not set an ordered flag on the queue, so xfs does not even attempt a barrier write, and will never use barriers on these block devices. I propose removing th; /archives/xfs/2008-06/msg00789.html (9,159 bytes)
9. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Timothy Shimmin <tes@xxxxxxx>; Date: Thu, 26 Jun 2008 18:25:40 +1000; Yeah, okay so we are revisiting this stuff again. Fair enough. (Groan;-) So it was brought to our attention by Neil a while ago: 1. Looking back, we agreed at the time that this seemed reasonable. (s; /archives/xfs/2008-06/msg00809.html (19,380 bytes)
10. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Thu, 26 Jun 2008 08:25:11 -0500; But that's an admin issue. The way it is now, for example a home user of md raid1 (me!) can't run barriers even if they wanted to. Until there is a way to know if a write cache is non-volatile the on; /archives/xfs/2008-06/msg00827.html (10,475 bytes)
11. RE: [PATCH] disable queue flag test in barrier check (score: 1): Author: "David Lethe" <david@xxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 09:47:19 -0500; Not sure what you mean about non-volatile vs. volatile write cache, however. If you want to see if write cache is enabled on a disk drive, or Even a logical disk on a hardware-based RAId, under Linux; /archives/xfs/2008-06/msg00828.html (12,263 bytes)
12. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Thu, 26 Jun 2008 09:57:18 -0500; I'm not so interested in whether it is enabled; I'd like to know if it is safe (to varying degrees) in the event of a power failure, and I don't think there's any way we can know that. So the adminis; /archives/xfs/2008-06/msg00829.html (10,011 bytes)
13. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: "David Lethe" <david@xxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 10:24:00 -0500; Unflushed writes are 100% effective for losing data and corrupting file systems. Data isn't saved until it is on the magnetic media. Batterybackup modules for disk controllers help, but there is no s; /archives/xfs/2008-06/msg00830.html (10,898 bytes)
14. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Timothy Shimmin <tes@xxxxxxx>; Date: Fri, 27 Jun 2008 14:51:41 +1000; I understand what you are saying. I agree. And I agreed when it went out last time. But as it has: <- gone out I want to make sure that everyone is happy for it to go back out again. (Cut the string; /archives/xfs/2008-06/msg00849.html (11,144 bytes)
15. [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Wed, 25 Jun 2008 22:07:22 -0500; md raid1 can pass down barriers, but does not set an ordered flag on the queue, so xfs does not even attempt a barrier write, and will never use barriers on these block devices. I propose removing th; /archives/xfs/2008-06/msg01249.html (9,159 bytes)
16. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Timothy Shimmin <tes@xxxxxxx>; Date: Thu, 26 Jun 2008 18:25:40 +1000; Yeah, okay so we are revisiting this stuff again. Fair enough. (Groan;-) So it was brought to our attention by Neil a while ago: 1. Looking back, we agreed at the time that this seemed reasonable. (s; /archives/xfs/2008-06/msg01269.html (19,428 bytes)
17. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Thu, 26 Jun 2008 08:25:11 -0500; But that's an admin issue. The way it is now, for example a home user of md raid1 (me!) can't run barriers even if they wanted to. Until there is a way to know if a write cache is non-volatile the on; /archives/xfs/2008-06/msg01287.html (10,547 bytes)
18. RE: [PATCH] disable queue flag test in barrier check (score: 1): Author: "David Lethe" <david@xxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 09:47:19 -0500; Not sure what you mean about non-volatile vs. volatile write cache, however. If you want to see if write cache is enabled on a disk drive, or Even a logical disk on a hardware-based RAId, under Linux; /archives/xfs/2008-06/msg01288.html (12,385 bytes)
19. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Thu, 26 Jun 2008 09:57:18 -0500; I'm not so interested in whether it is enabled; I'd like to know if it is safe (to varying degrees) in the event of a power failure, and I don't think there's any way we can know that. So the adminis; /archives/xfs/2008-06/msg01289.html (10,173 bytes)
20. Re: [PATCH] disable queue flag test in barrier check (score: 1): Author: "David Lethe" <david@xxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 10:24:00 -0500; Unflushed writes are 100% effective for losing data and corrupting file systems. Data isn't saved until it is on the magnetic media. Batterybackup modules for disk controllers help, but there is no s; /archives/xfs/2008-06/msg01290.html (10,898 bytes)

Current List: 1 - 20
Page: [1] [2]