[PATCH v3 09/24] fs: btrfs: Use ktime_get_real_ts for root ctime

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

Re: Trying to rescue my data :(

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

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

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

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

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

Re: Trying to rescue my data :(

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

Re: Adventures in btrfs raid5 disk recovery

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,

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

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

Re: Adventures in btrfs raid5 disk recovery

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

Re: Bad hard drive - checksum verify failure forces readonly mount

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 [

Re: Bad hard drive - checksum verify failure forces readonly mount

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

Re: Trying to rescue my data :(

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

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

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

Re: Trying to rescue my data :(

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

Re: Trying to rescue my data :(

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

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

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

[PATCH v3 00/24] Delete CURRENT_TIME_SEC and replace current_fs_time()

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.

[GIT PULL 1/2] Btrfs

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

Re: Bad hard drive - checksum verify failure forces readonly mount

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"

[GIT PULL 2/2] Btrfs

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

[BUG] Btrfs scrub sometime recalculate wrong parity in raid5

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