Re: BTRFS Error - Rockstor

Anything interesting in dmesg? That looks similar to the kind of problems I had when I had a disk fail. On Thu, Nov 12, 2015 at 4:08 PM, Scotty Edmonds wrote: > I get this: > > [root@rockstor ~]# btrfs check /dev/sdd > checksum verify failed on 12060305965056 found

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

I've uploaded the full output of btrfs check on that device to: http://christoph.anton.mitterer.name/tmp/public/cbec6446-898b-11e5-90a4-502690aa641f.xz there are nearly 600k of these error lines... WTF?! Also, the filesystem still mounts (without any errors to dmesg) Any help would be

Re: [RFCv3.1 00/11] xfstests: test the nfs/cifs/btrfs/xfs reflink/dedupe ioctls

Looks fine: Acked-by: Christoph Hellwig some of the free block range stuff might need minor fixups for certain file systems later, but I'd rather do this once all the patches are merged. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

re: btrfs: extend balance filter usage to take minimum and maximum

Hello David Sterba, The patch bc3094673f22: "btrfs: extend balance filter usage to take minimum and maximum" from Oct 20, 2015, leads to the following static checker warning: fs/btrfs/volumes.c:3063 update_balance_args() warn: we tested 'bctl->data.flags & (1 << 8)' before and it

Re: [PATCH] btrfs-progs: Fix partitioned loop devices resolve.

New patch is attached. On 11/10/2015 12:50 PM, Karel Zak wrote: > > Yep, first try /sys/... and when unsuccessful then try ioctl. > > losetup example: > https://github.com/karelzak/util-linux/blob/master/lib/loopdev.c#L686 > > (it's probably too complex, but the basic idea is obvious) > >

Re: BTRFS Error - Rockstor

On Thu, Nov 12, 2015 at 4:24 PM, Scotty Edmonds wrote: > Not exactly sure what to look for in dmesg.. If it is a disk fail shouldn't > I just be able to remove the disk as it's RAID5? > Yes theoretically. > [ 20.323997] BTRFS: device label seagate3x2tb devid 2

bad extent [5993525264384, 5993525280768), type mismatch with chunk

Hey. I get these errors on fsck'ing a btrfs: bad extent [5993525264384, 5993525280768), type mismatch with chunk bad extent [5993525280768, 5993525297152), type mismatch with chunk bad extent [5993525297152, 5993525313536), type mismatch with chunk bad extent [5993529442304, 5993529458688), type

Re: BTRFS Error - Rockstor

On IRC earlier, I asked for the btrfs-debug-tree output of the broken tree block (1205030...etc). Since it's also failing, that would kind of indicate that this is pretty badly broken for some reason. It doesn't quite feel like a broken disk to me, but I'm not sure what _has_ happened.

Re: [PATCH 00/15] btrfs: Hot spare and Auto replace

Austin S Hemmelgarn wrote on 2015/11/12 08:04 -0500: On 2015-11-11 21:15, Qu Wenruo wrote: Hi Anand, Nice work. But I have some small questions about it. Anand Jain wrote on 2015/11/09 18:56 +0800: These set of patches provides btrfs hot spare and auto replace support for you review and

Re: BTRFS Error - Rockstor

Thanks for the help, I got the same error on all variants. [root@rockstor ~]# btrfs check --readonly -s 0 /dev/sdh using SB copy 0, bytenr 65536 checksum verify failed on 12060305965056 found 779CCA23 wanted A746C37A checksum verify failed on 12060305965056 found 779CCA23 wanted A746C37A

Re: [PATCH 00/15] btrfs: Hot spare and Auto replace

On 2015-11-11 21:15, Qu Wenruo wrote: Hi Anand, Nice work. But I have some small questions about it. Anand Jain wrote on 2015/11/09 18:56 +0800: These set of patches provides btrfs hot spare and auto replace support for you review and comments. First, here below are the simple example steps

Re: Ideas for btrfs-convert fix(or rework)

[ resending as it didnt get through. ] I got different opinion. btrfs-convert is something that brought me to btrfs. While there are other bugs to fix, someone dedicating time to fix btrfs-convert is of high interest to me. Sending right message to community, might make some rolling distros to

Re: Potential to loose data in case of disk failure

On 2015-11-11 15:24, Sean Greenslade wrote: On Wed, Nov 11, 2015 at 11:30:57AM -0600, Jim Murphy wrote: Hi all, What am I missing or misunderstanding? I have a newly purchased laptop I want/need to multi boot different OSs on. As a result after partitioning I have ended up with two

Re: Regression in btrfs: properly set the termination value of ctx->pos in readdir

On Wed, Nov 11, 2015 at 01:22:19PM +0100, Holger Hoffstätte wrote: > > the patch btrfs: properly set the termination value of ctx->pos in > > readdir introduces a regression to me. > > > > A lot of stuff runs in "endless" or long running loops. > > Just tested this and can confirm something is

Re: [RFCv3.1 00/11] xfstests: test the nfs/cifs/btrfs/xfs reflink/dedupe ioctls

On Thu, Nov 12, 2015 at 01:07:56AM -0800, Christoph Hellwig wrote: > Looks fine: > > Acked-by: Christoph Hellwig Actually I take this back. I had though this was the existing series with my fixes, but this one still incorrectly assumes that if reflink works dedup works as well,

Re: Regression in btrfs: properly set the termination value of ctx->pos in readdir

On Wed, Nov 11, 2015 at 12:57:30PM +0100, Stefan Priebe - Profihost AG wrote: > the patch btrfs: properly set the termination value of ctx->pos in > readdir introduces a regression to me. > > A lot of stuff runs in "endless" or long running loops. This might be related to the readdir fix but I

Re: illegal snapshot, cannot be deleted

On 2015-11-11 17:11, Vedran Vucic wrote: Hello, I use OpenSuse 13.2 on my Toshiba Satellite laptop. I noticed that I run out of disk space, checked documentation and I realized that there were many snapshots. I used Yast Snapper to delete snapshots. I noticed that one snapshot with number 748

Re: [PATCH v9 0/4] VFS: In-kernel copy system call

On 2015-11-11 09:53, Eric Biggers wrote: On Tue, Nov 10, 2015 at 04:53:30PM -0500, Anna Schumaker wrote: /* this could be relaxed once a method supports cross-fs copies */ if (inode_in->i_sb != inode_out->i_sb) return -EXDEV; This allows the same superblock but

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Latest fsck added a lot of more restrict check. Like this one, if any extent type doesn't match with its chunk, like metadata extent in a data chunk, btrfsck will report like that. The filesystem seems to be a converted one from ext*. If so, there is no real 100% stable method to recovery it,

Re: Ideas for btrfs-convert fix(or rework)

Austin S Hemmelgarn posted on Thu, 12 Nov 2015 09:38:03 -0500 as excerpted: > I'm not arguing that [btrfs-convert] should just go away, I'm trying to > argue that it shouldn't be a development priority if it works correctly. Agreed. If you go back to my reply that started this subthread, the

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Christoph Anton Mitterer posted on Fri, 13 Nov 2015 04:57:29 +0100 as excerpted: > As I've said I have these two 8TiB disks... one which is basically the > master with loads of precious data, the other being a backup from the > master, regularly created with incremental btrfs send/receive. 8 TiB

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Fri, 2015-11-13 at 11:23 +0800, Qu Wenruo wrote: > No, "-t 2" means only dump extent tree, no privacy issues at all. > Since only numeric inode/snapshot number and offset inside file. > Or I'll give you a warning on privacy. > > No file name at all, just try it yourself. I'm preparing it...

Re: Ideas for btrfs-convert fix(or rework)

On 2015-11-12 09:09, Roman Mamedov wrote: On Thu, 12 Nov 2015 08:27:49 -0500 Austin S Hemmelgarn wrote: know of (Arch and Gentoo), because the very fact that you installed a system with either one means that you are fully capable of backing up your data, and

Re: Regression in btrfs: properly set the termination value of ctx->pos in readdir

On 11/12/15 14:09, David Sterba wrote: > On Thu, Nov 12, 2015 at 11:35:23AM +0100, David Sterba wrote: >> On Wed, Nov 11, 2015 at 01:22:19PM +0100, Holger Hoffstätte wrote: the patch btrfs: properly set the termination value of ctx->pos in readdir introduces a regression to me.

Re: Regression in btrfs: properly set the termination value of ctx->pos in readdir

On Thu, Nov 12, 2015 at 11:35:23AM +0100, David Sterba wrote: > On Wed, Nov 11, 2015 at 01:22:19PM +0100, Holger Hoffstätte wrote: > > > the patch btrfs: properly set the termination value of ctx->pos in > > > readdir introduces a regression to me. > > > > > > A lot of stuff runs in "endless" or

Re: Ideas for btrfs-convert fix(or rework)

On 2015-11-12 05:23, Vytautas D wrote: [ resending as it didnt get through. ] I got different opinion. btrfs-convert is something that brought me to btrfs. While there are other bugs to fix, someone dedicating time to fix btrfs-convert is of high interest to me. Sending right message to

Re: Ideas for btrfs-convert fix(or rework)

On Thu, 12 Nov 2015 08:27:49 -0500 Austin S Hemmelgarn wrote: > know of (Arch and Gentoo), because the very fact that you installed a > system with either one means that you are fully capable of backing up > your data, and reprovisioning the system using BTRFS instead of

Re: [PATCH 00/15] btrfs: Hot spare and Auto replace

On 2015-11-09 11:56, Anand Jain wrote: > These set of patches provides btrfs hot spare and auto replace support > for you review and comments. Hi Anand, is there any reason to put this kind of logic in the kernel space ? I think that it could be more simply to create a daemon which checks the

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Hey. On Fri, 2015-11-13 at 10:13 +0800, Qu Wenruo wrote: > Like this one, if any extent type doesn't match with its chunk, like > metadata extent in a data chunk, btrfsck will report like that. So these errors... are they anything serious? I.e. like data loss/corruption? Or is it more a

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Christoph Anton Mitterer wrote on 2015/11/13 03:26 +0100: Hey. On Fri, 2015-11-13 at 10:13 +0800, Qu Wenruo wrote: Like this one, if any extent type doesn't match with its chunk, like metadata extent in a data chunk, btrfsck will report like that. So these errors... are they anything

[PATCH] btrfs-progs: find-root: Add support to search chunk root

Add support to search chunk root, as we only need to search tree roots in system chunk, which should be very easy to add, just iterate in system chunks. Signed-off-by: Qu Wenruo --- find-root.c | 18 -- volumes.c | 6 +++--- volumes.h | 16

Re: BTRFS Error - Rockstor

Got this: [root@rockstor ~]# btrfs-show-super -f /dev/sdg superblock: bytenr=65536, device=/dev/sdg - csum0x793978ef [match] bytenr 65536 flags 0x1 ( WRITTEN )

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Fri, 2015-11-13 at 11:23 +0800, Qu Wenruo wrote: > No, "-t 2" means only dump extent tree, no privacy issues at all. > Since only numeric inode/snapshot number and offset inside file. > Or I'll give you a warning on privacy. Done...

Re: BTRFS Error - Rockstor

Chunk root seems corrupted. But that's not a really huge problem, tree root corruption happens, and thanks to the full CoW of btrfs metadata, we will always be able to find a old version one. I'd like to do a full disk scan for any earlier version chunk root, but I found that btrfs-find-root

Re: BTRFS Error - Rockstor

Chunk root seems corrupted. But that's not a really huge problem, tree root corruption happens, and thanks to the full CoW of btrfs metadata, we will always be able to find a old version one. I'd like to do a full disk scan for any earlier version chunk root, but I found that btrfs-find-root

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Fri, 2015-11-13 at 10:52 +0800, Qu Wenruo wrote: > You can provide the output of "btrfs-debug-tree -t 2 " to help > further debug. > It would be quite big, so it's better to zip it. That would contain all the filenames, right? Hmm that could be problematic because of privacy issues... >

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

And I should perhaps mention one more thing: As I've said I have these two 8TiB disks... one which is basically the master with loads of precious data, the other being a backup from the master, regularly created with incremental btrfs send/receive. Everytime I did this (which is every two months

Re: BTRFS Error - Rockstor

Although I submitted a patch, that won't work for you. As I found that your whole chunk tree is corrupted, so I'll need to add a new mode for you to handle such case, which will be much time consuming than the patch I submitted... But your superblock should has some glue if we are in good

Re: BTRFS Error - Rockstor

Scotty Edmonds wrote on 2015/11/13 03:05 +: Got this: [root@rockstor ~]# btrfs-show-super -f /dev/sdg superblock: bytenr=65536, device=/dev/sdg - csum0x793978ef [match] bytenr 65536 flags

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Christoph Anton Mitterer wrote on 2015/11/13 04:03 +0100: On Fri, 2015-11-13 at 10:52 +0800, Qu Wenruo wrote: You can provide the output of "btrfs-debug-tree -t 2 " to help further debug. It would be quite big, so it's better to zip it. That would contain all the filenames, right? Hmm that

Re: BTRFS Error - Rockstor

yes, no problem. I had it powered off as I'm moving the system to a proper chassis and won't have it for another two weeks. Thanks, Scotty Edmonds sco...@scottyedmonds.com From: Qu Wenruo Sent: November-12-15 10:21 PM To:

understanding csum tree

Hi - I trying to understand csum tree and its entries. 1) create a filenamed 'ab' with 100KB of data. I can see csum entry for this: item 0 key (EXTENT_CSUM EXTENT_CSUM 4239360) itemoff 3895 itemsize 100 2) created another named 'zb1' with 100KB of data. I can't find csum entry for this.Looks

btrfs check error: btrfs_reserve_extent: Assertion `ret` failed.

I'll try and keep this short, so if you would like anymore information please let me know. This is a 5 disk raid5 mdadm array used for offsite backup. There is no backup of it, it is the backup. :) I would just like to save it if possible since it takes quite a long to time to do the initial

Re: Potential to loose data in case of disk failure

On 2015-11-12 12:23, Dmitry Katsubo wrote: On 2015-11-12 13:47, Austin S Hemmelgarn wrote: That's a pretty unusual setup, so I'm not surprised there's no quick and easy answer. The best solution in my opinion would be to shuffle your partitions around and combine sda3 and sda8 into a single

Re: [RFCv3.1 00/11] xfstests: test the nfs/cifs/btrfs/xfs reflink/dedupe ioctls

On Thu, Nov 12, 2015 at 04:51:15AM -0800, Christoph Hellwig wrote: > On Thu, Nov 12, 2015 at 01:07:56AM -0800, Christoph Hellwig wrote: > > Looks fine: > > > > Acked-by: Christoph Hellwig > > Actually I take this back. I had though this was the existing series > with my fixes, but

Re: Potential to loose data in case of disk failure

On 2015-11-12 13:47, Austin S Hemmelgarn wrote: >> That's a pretty unusual setup, so I'm not surprised there's no quick and >> easy answer. The best solution in my opinion would be to shuffle your >> partitions around and combine sda3 and sda8 into a single partition. >> There's generally no

Re: [RFCv3.1 00/11] xfstests: test the nfs/cifs/btrfs/xfs reflink/dedupe ioctls

On Thu, Nov 12, 2015 at 09:34:27AM -0800, Darrick J. Wong wrote: > Bleargh, _require_*_dedupe forgot to check for ENOTTY output, so all the > dedupe > tests should have _notrun. > > Also, generic/806 was calling the wrong _require. > > I'll start renumbering tests; Christoph, did you see

BTRFS Error - Rockstor

Rockstor was running great, I ordered a SuperMicro 24-bay Chassis and decided to power down the machine while I was away. When I turned it back on I got "Failed to read chunk tree" & "open_ctree failed" error (http://i.imgur.com/rGk9M57l.jpg) I spoke with support at Rockstor and they

Re: BTRFS Error - Rockstor

What does btrfs check without any repair options report? btrfs check /dev/sdd On Thu, Nov 12, 2015 at 12:48 PM, Scotty Edmonds wrote: > Rockstor was running great, I ordered a SuperMicro 24-bay Chassis and decided > to power down the machine while I was away. When I

Re: [PATCH 00/15] btrfs: Hot spare and Auto replace

On 2015-11-12 03:15, Qu Wenruo wrote: > Hi Anand, > > Nice work. > But I have some small questions about it. > > Anand Jain wrote on 2015/11/09 18:56 +0800: >> These set of patches provides btrfs hot spare and auto replace support >> for you review and comments. >> >> First, here below are the