Re: Raid 0 setup doubt.

Jose Otero posted on Mon, 28 Mar 2016 22:30:56 +0200 as excerpted: > Duncan, you are right. I have 8 GB of RAM, and the most memory intensive > thing I'll be doing is a VM for Windows. Now I double boot, but rarely > go into Win, only to play some game occasionally. So, I think I'll be > better

Re: Compression causes kernel crashes if there are I/O or checksum errors (was: RE: kernel BUG at fs/btrfs/volumes.c:5519 when hot-removing device in RAID-1)

James Johnston posted on Mon, 28 Mar 2016 14:34:14 + as excerpted: > Thanks for the corroborating report - it does sound to me like you ran > into the same problem I've found. (I don't suppose you ever captured > any of the crashes? If they assert on the same thing as me then it's > even

Re: [PATCH v2] fstest: btrfs: test single 4k extent after subpagesize buffered writes

On Wed, Mar 23, 2016 at 09:52:21PM -0700, Liu Bo wrote: > On Wed, Mar 23, 2016 at 07:53:38PM +0800, Eryu Guan wrote: > > On Tue, Mar 22, 2016 at 03:12:25PM -0700, Liu Bo wrote: > > > On Tue, Mar 22, 2016 at 12:00:13PM +0800, Eryu Guan wrote: > > > > On Thu, Mar 17, 2016 at 03:56:38PM -0700, Liu Bo

Re: Raid 0 setup doubt.

On Mon, Mar 28, 2016 at 6:35 AM, Austin S. Hemmelgarn wrote: > The other caveat that nobody seems to mention outside of specific cases is > that using suspend to disks exposes you to direct attack by anyone with the > ability to either physically access the system, or boot

Re: scrub: Tree block spanning stripes, ignored

Ivan P wrote on 2016/03/28 23:21 +0200: Well, the file in this inode is fine, I was able to copy it off the disk. However, rm-ing the file causes a segmentation fault. Shortly after that, I get a kernel oops. Same thing happens if I attempt to re-run scrub. How can I delete that inode? Could

Re: [PATCH v8 10/27] btrfs: dedupe: Add basic tree structure for on-disk dedupe method

Chris Mason wrote on 2016/03/28 10:09 -0400: On Sat, Mar 26, 2016 at 09:11:53PM +0800, Qu Wenruo wrote: On 03/25/2016 11:11 PM, Chris Mason wrote: On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote: Chris Mason wrote on 2016/03/24 16:58 -0400: Are you storing the entire hash, or

Re: Raid 0 setup doubt.

Austin S. Hemmelgarn posted on Mon, 28 Mar 2016 08:35:59 -0400 as excerpted: > The other caveat that nobody seems to mention outside of specific cases > is that using suspend to disks exposes you to direct attack by anyone > with the ability to either physically access the system, or boot an >

beruházás~

Hello, I am representing an investment interest from Dubai for which we seek your participation as an overseas representative. Reply on email below if interested. Email: philp...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: scrub: Tree block spanning stripes, ignored

Well, the file in this inode is fine, I was able to copy it off the disk. However, rm-ing the file causes a segmentation fault. Shortly after that, I get a kernel oops. Same thing happens if I attempt to re-run scrub. How can I delete that inode? Could deleting it destroy the filesystem beyond

Re: "bad metadata" not fixed by btrfs repair

On Mon, Mar 28, 2016 at 12:51 PM, Nazar Mokrynskyi wrote: >>> # btrfs check --repair /dev/mapper/fanbtr >>> bad metadata [4425377054720, 4425377071104) crossing stripe boundary >>> bad metadata [4425380134912, 4425380151296) crossing stripe boundary >>> bad metadata

Re: Raid 0 setup doubt.

Thanks a lot Duncan, Chris Murphy, James Johnston, and Austin. Thanks for the clear answer and the extra information to chew on. Duncan, you are right. I have 8 GB of RAM, and the most memory intensive thing I'll be doing is a VM for Windows. Now I double boot, but rarely go into Win, only to

Re: "bad metadata" not fixed by btrfs repair

On 2016-03-28 10:37, Marc Haber wrote: Hi, I have a btrfs which btrfs check --repair doesn't fix: # btrfs check --repair /dev/mapper/fanbtr bad metadata [4425377054720, 4425377071104) crossing stripe boundary bad metadata [4425380134912, 4425380151296) crossing stripe boundary bad metadata

Re: linux 4.4.3 oops on aborted transaction, forces FS read-only

It appears this issue has been caused by space cache corruption preventing allocation of new meta data on the filesystem(8 device RAID-10 for meta data.) I've now been running nospace_cache for the past couple of weeks of my heavy rsync traffic without any failures. It's certainly slower, but the

Re: "bad metadata" not fixed by btrfs repair

On Mon, Mar 28, 2016 at 06:51:02PM +, Hugo Mills wrote: >"Could not find root 8" is harmless (and will be going away as a > message soon). It just means that systemd is probing the FS for > quotas, and you don't have quotas enabled. *phew* That message was not what I wanted to read on

Re: "bad metadata" not fixed by btrfs repair

I have the same thing with kernel 4.5 and btrfs-progs 4.4. Wrote about it 2 weeks ago and didn't get any answer: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg51609.html However, despite those messages everything seems to work fine. Sincerely, Nazar Mokrynskyi

Re: "bad metadata" not fixed by btrfs repair

On Mon, Mar 28, 2016 at 08:42:37PM +0200, Marc Haber wrote: > On Mon, Mar 28, 2016 at 04:37:14PM +0200, Marc Haber wrote: > > I have a btrfs which btrfs check --repair doesn't fix: > > > > # btrfs check --repair /dev/mapper/fanbtr > > bad metadata [4425377054720, 4425377071104) crossing stripe

Re: "bad metadata" not fixed by btrfs repair

On Mon, Mar 28, 2016 at 04:37:14PM +0200, Marc Haber wrote: > I have a btrfs which btrfs check --repair doesn't fix: > > # btrfs check --repair /dev/mapper/fanbtr > bad metadata [4425377054720, 4425377071104) crossing stripe boundary > bad metadata [4425380134912, 4425380151296) crossing stripe

best way to make space_cache=v2 default?

Hi, what's the best way to make space_cache=v2 the default in my custom kernel build? Greets, Stefan -- 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

"bad metadata" not fixed by btrfs repair

Hi, I have a btrfs which btrfs check --repair doesn't fix: # btrfs check --repair /dev/mapper/fanbtr bad metadata [4425377054720, 4425377071104) crossing stripe boundary bad metadata [4425380134912, 4425380151296) crossing stripe boundary bad metadata [4427532795904, 4427532812288) crossing

RE: Compression causes kernel crashes if there are I/O or checksum errors (was: RE: kernel BUG at fs/btrfs/volumes.c:5519 when hot-removing device in RAID-1)

Hi, Thanks for the corroborating report - it does sound to me like you ran into the same problem I've found. (I don't suppose you ever captured any of the crashes? If they assert on the same thing as me then it's even stronger evidence.) > The failure mode of this particular ssd was premature

Re: btrfs_destroy_inode WARN_ON.

On 2016.03.28 at 10:05 -0400, Josef Bacik wrote: > >Mar 24 10:37:27 x4 kernel: WARNING: CPU: 3 PID: 11838 at > >fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x22b/0x2a0 > > I saw this running some xfstests on our internal kernels but haven't been > able to reproduce it on my latest enospc work

Re: [PATCH v8 10/27] btrfs: dedupe: Add basic tree structure for on-disk dedupe method

On Sat, Mar 26, 2016 at 09:11:53PM +0800, Qu Wenruo wrote: > > > On 03/25/2016 11:11 PM, Chris Mason wrote: > >On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote: > >> > >> > >>Chris Mason wrote on 2016/03/24 16:58 -0400: > >>>Are you storing the entire hash, or just the parts not

Re: btrfs_destroy_inode WARN_ON.

On 03/25/2016 04:25 AM, Markus Trippelsdorf wrote: On 2016.03.24 at 18:54 -0400, Dave Jones wrote: Just hit this on a tree from earlier this morning, v4.5-11140 or so. WARNING: CPU: 2 PID: 32570 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x389/0x3f0 [btrfs] CPU: 2 PID: 32570 Comm: rm Not

Re: Raid 0 setup doubt.

On 2016-03-27 20:56, Duncan wrote: But there's another option you didn't mention, that may be useful, depending on your exact need and usage of that swap: Split your swap space in half, say (roughly, you can make one slightly larger than the other to allow for the EFI on one device) 8 GiB on

Re: Possible Raid Bug

On 28 March 2016 at 05:54, Anand Jain wrote: > > On 03/26/2016 07:51 PM, Patrik Lundquist wrote: >> >> # btrfs device stats /mnt >> >> [/dev/sde].write_io_errs 11 >> [/dev/sde].read_io_errs0 >> [/dev/sde].flush_io_errs 2 >> [/dev/sde].corruption_errs 0 >>

Re: csum errors in VirtualBox VDI files

Am Sun, 27 Mar 2016 13:04:25 -0600 schrieb Chris Murphy : > As for the csum errors with this one single VDI file, you're going to > have to come up with a way to reproduce it consistently. You'll need > to have a good copy on a filesystem that comes up clean with btrfs >

Re: Compression causes kernel crashes if there are I/O or checksum errors (was: RE: kernel BUG at fs/btrfs/volumes.c:5519 when hot-removing device in RAID-1)

James Johnston posted on Mon, 28 Mar 2016 04:41:24 + as excerpted: > After puzzling over the btrfs failure I reported here a week ago, I > think there is a bad incompatibility between compression and RAID-1 > (maybe other RAID levels too?). I think it is unsafe for users to use >

bad metadata crossing stripe boundary (was: csum errors in VirtualBox VDI files)

Changing subject to reflect the current topic... Am Sun, 27 Mar 2016 21:55:40 +0800 schrieb Qu Wenruo : > > I finally got copy data: > > > > # before mounting let's check the FS: > > > > $ sudo btrfsck /dev/disk/by-label/usb-backup > > Checking filesystem on

Re: Raid 0 setup doubt.

James Johnston posted on Mon, 28 Mar 2016 05:26:56 + as excerpted: > For me, I use swap on an SSD, which is orders of magnitude faster than > HDD. > Swap can still be useful on an SSD and can really close the gap between > RAM speeds and swap speeds. (The original poster would do well to use

Re: btrfs filesystem du - Failed to lookup root id - Inappropriate ioctl for device

2016-03-27 22:26 GMT+02:00 Peter Becker : > Hi i found the descriped error in if i execute du with btrfs-progs > v4.5 with kernel v4.5. > > floyd@nas ~ $ sudo btrfs version > btrfs-progs v4.5 > > floyd@nas ~ $ uname -r > 4.5.0-040500-generic > > floyd@nas ~ $ sudo btrfs fi