On 4 April 2018 at 22:00, Craig Ringer <cr...@2ndquadrant.com> wrote:
> It's the error reporting issues around closing and reopening files with > outstanding buffered I/O that's really going to hurt us here. I'll be > expanding my test case to cover that shortly. > > Also, just to be clear, this is not in any way confined to xfs and/or lvm as I originally thought it might be. Nor is ext3/ext4's errors=remount-ro protective. data_err=abort doesn't help either (so what does it do?). What bewilders me is that running with data=journal doesn't seem to be safe either. WTF? [26438.846111] EXT4-fs (dm-0): mounted filesystem with journalled data mode. Opts: errors=remount-ro,data_err=abort,data=journal [26454.125319] EXT4-fs warning (device dm-0): ext4_end_bio:323: I/O error 10 writing to inode 12 (offset 0 size 0 starting block 59393) [26454.125326] Buffer I/O error on device dm-0, logical block 59393 [26454.125337] Buffer I/O error on device dm-0, logical block 59394 [26454.125343] Buffer I/O error on device dm-0, logical block 59395 [26454.125350] Buffer I/O error on device dm-0, logical block 59396 and splat, there goes your data anyway. It's possible that this is in some way related to using the device-mapper "error" target and a loopback device in testing. But I don't really see how. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
