On 26/06/16 12:30, Duncan wrote:
> Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted:
>
>> In every case, it was a flurry of csum error messages, then instant
>> death.
>
> This is very possibly a known bug in btrfs, that occurs even in raid1
> where a later scrub repairs all c
Chris Murphy posted on Sat, 25 Jun 2016 11:25:05 -0600 as excerpted:
> Wow. So it sees the data strip corruption, uses good parity on disk to
> fix it, writes the fix to disk, recomputes parity for some reason but
> does it wrongly, and then overwrites good parity with bad parity?
> That's fucked.
Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted:
> In every case, it was a flurry of csum error messages, then instant
> death.
This is very possibly a known bug in btrfs, that occurs even in raid1
where a later scrub repairs all csum errors. While in theory btrfs raid1
sho
On Sat, Jun 25, 2016 at 12:42 PM, Goffredo Baroncelli
wrote:
> On 2016-06-25 19:58, Chris Murphy wrote:
> [...]
>>> Wow. So it sees the data strip corruption, uses good parity on disk to
>>> fix it, writes the fix to disk, recomputes parity for some reason but
>>> does it wrongly, and then overwri
Interestingly enough, so far I'm finding with full stripe writes, i.e.
3x raid5, exactly 128KiB data writes, devid 3 is always parity. This
is raid4. So...I wonder if some of these slow cases end up with a
bunch of stripes that are effectively raid4-like, and have a lot of
parity overwrites, which
The series is aimed at getting rid of CURRENT_TIME, CURRENT_TIME_SEC macros
and replacing current_fs_time() with current_time().
The macros are not y2038 safe. There is no plan to transition them into being
y2038 safe.
ktime_get_* api's can be used in their place. And, these are y2038 safe.
CURREN
btrfs_root_item maintains the ctime for root updates.
This is not part of vfs_inode.
Since current_time() uses struct inode* as an argument
as Linus suggested, this cannot be used to update root
times unless, we modify the signature to use inode.
Since btrfs uses nanosecond time granularity, it c
On Sat, Jun 25, 2016 at 2:10 PM, Vasco Almeida wrote:
> Citando Chris Murphy :
>>
>> I would do a couple things in order:
>> 1. Mount ro and copy off what you want in case the whole thing gets
>> worse and can't ever be mounted again.
>> 2. Mount with only these options: -o skip_balance,subvolid=
Citando Chris Murphy :
On Fri, Jun 24, 2016 at 6:06 PM, Vasco Almeida wrote:
Citando Chris Murphy :
dmesg http://paste.fedoraproject.org/384352/80842814/
[ 1837.386732] BTRFS info (device dm-9): continuing balance
[ 1838.006038] BTRFS info (device dm-9): relocating block group
15799943168 fl
On 2016-06-25 19:58, Chris Murphy wrote:
[...]
>> Wow. So it sees the data strip corruption, uses good parity on disk to
>> fix it, writes the fix to disk, recomputes parity for some reason but
>> does it wrongly, and then overwrites good parity with bad parity?
>
> The wrong parity, is it valid f
On Sat, Jun 25, 2016 at 11:25 AM, Chris Murphy wrote:
> On Sat, Jun 25, 2016 at 6:21 AM, Goffredo Baroncelli
> wrote:
>
>> 5) I check the disks at the offsets above, to verify that the data/parity is
>> correct
>>
>> However I found that:
>> 1) if I corrupt the parity disk (/dev/loop2), scrub d
On Sat, Jun 25, 2016 at 6:21 AM, Goffredo Baroncelli wrote:
> 5) I check the disks at the offsets above, to verify that the data/parity is
> correct
>
> However I found that:
> 1) if I corrupt the parity disk (/dev/loop2), scrub don't find any
> corruption, but recomputed the parity (always cor
On Sat, Jun 25, 2016 at 10:39 AM, Steven Haigh wrote:
> Well, I did end up recovering the data that I cared about. I'm not
> really keen to ride the BTRFS RAID6 train again any time soon :\
>
> I now have the same as I've had for years - md RAID6 with XFS on top of
> it. I'm still copying data ba
On Fri, Jun 24, 2016 at 12:19 PM, Austin S. Hemmelgarn
wrote:
> Well, the obvious major advantage that comes to mind for me to checksumming
> parity is that it would let us scrub the parity data itself and verify it.
OK but hold on. During scrub, it should read data, compute checksums
*and* pari
On 26/06/16 02:25, Chris Murphy wrote:
> On Fri, Jun 24, 2016 at 10:19 PM, Steven Haigh wrote:
>
>>
>> Interesting though that EVERY crash references:
>> kernel BUG at fs/btrfs/extent_io.c:2401!
>
> Yeah because you're mounted ro, and if this is 4.4.13 unmodified btrfs
> from kernel.org
On Fri, Jun 24, 2016 at 10:19 PM, Steven Haigh wrote:
>
> Interesting though that EVERY crash references:
> kernel BUG at fs/btrfs/extent_io.c:2401!
Yeah because you're mounted ro, and if this is 4.4.13 unmodified btrfs
from kernel.org then that's the 3rd line:
if (head->is_data) {
Hi Linus,
Btrfs part two was supposed to be a single patch on part of v4.7-rc4.
Somehow I didn't notice that my part2 branch repeated a few of the
patches in part 1 when I set it up earlier this week. Cherry-picking
gone wrong as I folded a fix into Dave Sterba's original integration.
I've been
On Fri, Jun 24, 2016 at 6:06 PM, Vasco Almeida wrote:
> Citando Chris Murphy :
>> A lot of changes have happened since 4.1.2 I would still use something
>> newer and try to repair it.
>
>
> By repair do you mean issue "btrfs check --repair /device" ?
Once you have copied off the important stuff,
Hi Linus,
I have a two part pull this time because one of the patches Dave Sterba
collected needed to be against v4.7-rc2 or higher (we used rc4). I try
to make my for-linus-xx branch testable on top of the last major
so we can hand fixes to people on the list more easily, so I've split
this pull
Hi all,
following the thread "Adventures in btrfs raid5 disk recovery", I investigated
a bit the BTRFS capability to scrub a corrupted raid5 filesystem. To test it, I
first find where a file was stored, and then I tried to corrupt the data disks
(when unmounted) or the parity disk.
The result s
20 matches
Mail list logo