| 1 |
Am 31.08.2016 um 16:33 schrieb Michael Mol: |
| 2 |
> |
| 3 |
> In data=journal mode, the contents of files pass through the journal as well, |
| 4 |
> ensuring that, at least as far as the filesystem's responsibility is concerned, |
| 5 |
> the data will be intact in the event of a crash. |
| 6 |
|
| 7 |
a common misconception. But not true at all. Google a bit. |
| 8 |
> |
| 9 |
> Now, I can still think of ways you can lose data in data=journal mode: |
| 10 |
> |
| 11 |
> * You mounted the filesystem with barrier=0 or with nobarrier; this can result |
| 12 |
|
| 13 |
not needed. |
| 14 |
|
| 15 |
> in data writes going to disk out of order, if the I/O stack supports barriers. |
| 16 |
> If you say "my file is ninety bytes" "here are ninety bytes of data, all 9s", |
| 17 |
> "my file is now thirty bytes", "here are thirty bytes of data, all 3s", then in |
| 18 |
> the end you should have a thirty-byte file filled with 3s. If you have barriers |
| 19 |
> enabled and you crash halfway through the whole process, you should find a file |
| 20 |
> of ninety bytes, all 9s. But if you have barriers disabled, the data may hit |
| 21 |
> disk as though you'd said "my file is ninety bytes, here are ninety bytes of |
| 22 |
> data, all 9s, here are thirty bytes of data, all 3s, now my file is thirty |
| 23 |
> bytes." If that happens, and you crash partway through the commit to disk, you |
| 24 |
> may see a ninety-byte file consisting of thirty 3s and sixty 9s. Or things may |
| 25 |
> landthat you see a thirty-byte file of 9s. |
| 26 |
> |
| 27 |
> * Your application didn't flush its writes to disk when it should have. |
| 28 |
|
| 29 |
not needed either. |
| 30 |
|
| 31 |
> |
| 32 |
> * Your vm.dirty_bytes or vm.dirty_ratio are too high, you've been writing a |
| 33 |
> lot to disk, and the kernel still has a lot of data buffered waiting to be |
| 34 |
> written. (Well, that can always lead to data loss regardless of how high those |
| 35 |
> settings are, which is why applications should flush their writes.) |
| 36 |
> |
| 37 |
> * You've used hdparm to enable write buffers in your hard disks, and your hard |
| 38 |
> disks lose power while their buffers have data waiting to be written. |
| 39 |
> |
| 40 |
> * You're using a buggy disk device that does a poor job of handling power |
| 41 |
> loss. Such as some SSDs which don't have large enough capacitors for their own |
| 42 |
> write reordering. Or just about any flash drive. |
| 43 |
> |
| 44 |
> * There's a bug in some code, somewhere. |
| 45 |
|
| 46 |
nope. |
| 47 |
> In-memory corruption of a data is a universal hazard. ECC should be the norm, |
| 48 |
> not the exception, honestly. |
| 49 |
> |
Archives