Nicholas D Steeves posted on Wed, 06 Apr 2016 00:04:36 -0400 as excerpted:
> Ah, that's exactly what I was looking for! Thank you. It took forever,
> and brought me back to what it was like to fsck large ext2 volumes. Is
> btrfs check conceptually identical to a read-only fsck of a ext2 volume?
Hi Alex,
On 13 March 2016 at 05:51, Alex Lyakas wrote:
> Nicholas,
>
> On Sat, Mar 12, 2016 at 12:19 AM, Nicholas D Steeves
> wrote:
>> On 10 March 2016 at 06:10, Alex Lyakas wrote:
>> Does this mean there is a good chance that everyone has corrupted
>> metadata?
> No, this definitely does not
On Thu, Mar 10, 2016 at 11:10 AM, Alex Lyakas wrote:
> csum_dirty_buffer was issuing a warning in case the extent buffer
> did not look alright, but was still returning success.
> Let's return error in this case, and also add an additional sanity
> check on the extent buffer header.
> The caller u
Nicholas,
On Sat, Mar 12, 2016 at 12:19 AM, Nicholas D Steeves wrote:
> On 10 March 2016 at 06:10, Alex Lyakas wrote:
>> csum_dirty_buffer was issuing a warning in case the extent buffer
>> did not look alright, but was still returning success.
>> Let's return error in this case, and also add an
On 10 March 2016 at 06:10, Alex Lyakas wrote:
> csum_dirty_buffer was issuing a warning in case the extent buffer
> did not look alright, but was still returning success.
> Let's return error in this case, and also add an additional sanity
> check on the extent buffer header.
> The caller up the c
csum_dirty_buffer was issuing a warning in case the extent buffer
did not look alright, but was still returning success.
Let's return error in this case, and also add an additional sanity
check on the extent buffer header.
The caller up the chain may BUG_ON on this, for example flush_epd_write_bio
