Re: Btrfs tragedy: lack of space for metadata leads to loss of fs.

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

On 2015-08-25 10:26, Miguel Negrão wrote:
> Austin S Hemmelgarn <ahferroin7 <at> gmail.com> writes:
>
>> One comment I would like to make about this: I have heard numerous
>> stories of OCZ brand SSD's having significant data corruption issues
>> (along the lines of writes returning successful when they really failed,
>> and blocks that are in use getting randomly erased) that can cause
>> severe data loss and filesystem problems.  While I do think that btrfs
>> needs to be improved when faced with such things, I would not at all be
>> surprised if the SSD was the root cause of the issue.
>>
>>
>
>
> It did have some corruption through its 3 year life time. This was from one
> month ago:
>
> sudo btrfs device stats /
>
> [/dev/sda5].write_io_errs   0
> [/dev/sda5].read_io_errs    0
> [/dev/sda5].flush_io_errs   0
> [/dev/sda5].corruption_errs 996
> [/dev/sda5].generation_errs 0
>
> On the latest scrub that I took note of the results though, it didn't have
> corruption:
>
> sudo btrfs scrub status /
> scrub status for f2e4e4d3-2d8e-4764-a818-de9176405c4b
> 	scrub started at Fri Apr 17 14:42:47 2015 and finished after 146 seconds
> 	total bytes scrubbed: 66.10GiB with 0 errors
IIRC, scrub (or at least the old versions) only reports the errors it 
finds, not cumulative ones (hence the device stats sub-command), so I'd 
still suggest being cautious.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]