Hi David, We are using 4.1 progs and 4.1 kernel on Rockstor currently and what I see is that btrfs check says device is not currently mounted. Is 4.1 effected? Do you recommend we update to 4.1.2 anyway?
[root@RockStor ~]# btrfs fi show testpool; mount | grep testpool; btrfs check /dev/sdaa; btrfs check /dev/sdab Label: 'testpool' uuid: ed600942-f300-4a01-aa49-6b0ab6c0b8f9 Total devices 2 FS bytes used 3.69GiB devid 1 size 2.00GiB used 2.00GiB path /dev/sdaa devid 2 size 2.00GiB used 2.00GiB path /dev/sdab btrfs-progs v4.1 /dev/sdaa on /mnt2/testpool type btrfs (rw,relatime,space_cache) /dev/sdac on /mnt2/testpool2 type btrfs (rw,relatime,space_cache) /dev/sdaa is currently mounted. Aborting. /dev/sdab is currently mounted. Aborting. On Tue, Jul 14, 2015 at 5:06 AM, David Sterba <dste...@suse.com> wrote: > Hi, > > due to a buggy bugfix to mkfs, filesystems created with version 4.1.1 are not > entirely correct. > > To check if the filesystem is affected run 'btrfs check' and look for > > Chunk[256, 228, 0]: length(4194304), offset(0), type(2) mismatch with block > group[0, 192, 4194304]: offset(4194304), objectid(0), flags(34) > Chunk[256, 228, 4194304]: length(8388608), offset(4194304), type(4) mismatch > with block group[4194304, 192, 8388608]: offset(8388608), objectid(4194304), > flags(36) > > at the beginning of the output. Such filesystems must not be used and > must be recreated. Read-only mount should be safe to retrieve the data, > but at the moment this hasn't been verified. > > Thanks to Qu Wenruo for identifying the problem, I'm sorry for the trouble. > > Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/ > Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
