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