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

On 04/12/2015 01:47, Qu Wenruo wrote: > [run btrfsck] I did that, too with an old btrfsck version (4.0) and it found the following errors. Then I did a btrfsck --repair, and I have been able to complete my "du -s" test. The next step will we to run a "btrfs scrub" to check if data loss did

Re: Subvolume UUID, data corruption?

On 2015-12-05 07:01, Hugo Mills wrote: On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer wrote: On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote: I don't think it'll cause problems. Is there any guaranteed behaviour when btrfs encounters two filesystems (i.e. not talking

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

On 04/12/2015 01:47, Qu Wenruo wrote: > The chunk mismatch problem should be resolved already, as the patch is merged > in david's devel branch. Great ! I am looking forward to a new release with this bug fix... > But for the kernel abort transaction, I'm sorry there is no good clue yet. >

Re: new oops in 4.4.0-rc4

On Thu, Dec 10, 2015 at 10:36:17AM -0600, Jon Christopherson wrote: > Hello, > > I noticed this new oops since running 4.4.0-rc4. Happens shortly after boot > and pretty much kills the system: > > > [ 177.774250] [ cut here ] > >[ 177.774256] kernel BUG at

Re: attacking btrfs filesystems via UUID collisions?

Sorry, I'm just about to change my mail system, and used a bogus test From: address in the previous mail (please replace fo@fo with cales...@scientia.net). Apologies for any inconveniences and this noise here. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature

Re: attacking btrfs filesystems via UUID collisions?

On Thu, 2015-12-10 at 12:42 -0700, Chris Murphy wrote: > That isn't what I'm suggesting. In the multiple device volume case > where there are two exact (same UUID, same devid, same generation) > instances of one of the block devices, Btrfs could randomly choose > either one if it's an RO mount.

Re: attacking btrfs filesystems via UUID collisions?

On Fri, Dec 11, 2015 at 3:21 PM, Christoph Anton Mitterer wrote: > On Thu, 2015-12-10 at 12:42 -0700, Chris Murphy wrote: >> That isn't what I'm suggesting. In the multiple device volume case >> where there are two exact (same UUID, same devid, same generation) >> instances of one of the

Re: attacking btrfs filesystems via UUID collisions?

On Wed, 2015-12-09 at 22:48 +0100, S.J. wrote: > > 3. Some way to fail gracefully, when there's ambiguity that cannot > > be > > resolved. Once there are duplicate devs (dd or lvm snapshots, etc) > > then there's simply no way to resolve the ambiguity automatically, > > and > > the volume should

Re: attacking btrfs filesystems via UUID collisions?

On 12/11/15 4:21 PM, Christoph Anton Mitterer wrote: >> Note that Btrfs is >> > not unique, XFS v5 does a very similar thing with volume UUID as >> > well, >> > and resulted in this change: >> > http://oss.sgi.com/pipermail/xfs/2015-April/041267.html > Do you mean that xfs may suffer from the

Re: attacking btrfs filesystems via UUID collisions?

A bit more about the dd-is-bad-topic: IMHO it doesn't matter at all. a) For this specific problem here, fixing a security problem automatically fixes the risk of data corruption because careless cloning+mounting (without UUID adjustments) too. So, if the user likes to use dd with its

Will "btrfs check --repair" fix the mounting problem?

Btrfs crashes in few seconds after mounting RW. If it's important: the volume was converted from ext4. "ext2_saved" subvolume still presents. dmesg: [ 625.998387] BTRFS info (device sda1): disk space caching is enabled [ 625.998392] BTRFS: has skinny extents [ 627.727708] BTRFS: checking UUID

Transaction aborted (error -17) during balance

Hi, during a balance on my main notebook, I have received the following call trace: [ 1545.229672] [ cut here ] [ 1545.229688] WARNING: CPU: 4 PID: 5545 at /build/linux-eGTGmU/linux-4.3/fs/btrfs/extent-tree.c:2093 __btrfs_inc_extent_ref.isra.52+0x20e/0x280 [btrfs]() [

Re: new oops in 4.4.0-rc4

On 12/11/2015 09:35 AM, Chris Mason wrote: On Thu, Dec 10, 2015 at 10:36:17AM -0600, Jon Christopherson wrote: Dave Jones sent in a report about this with trinity too, I'm digging in today. Since you can trigger this reliably, what was the last known-good kernel for you? -chris Hello,

Re: Will "btrfs check --repair" fix the mounting problem?

On Fri, Dec 11, 2015 at 10:50 AM, Ivan Sizov wrote: > Btrfs crashes in few seconds after mounting RW. > If it's important: the volume was converted from ext4. "ext2_saved" > subvolume still presents. > > dmesg: > [ 625.998387] BTRFS info (device sda1): disk space caching is

Re: [PATCH] Btrfs: fix transaction handle leak in balance

On Thu, Dec 10, 2015 at 11:16:27AM +, fdman...@kernel.org wrote: > From: Filipe Manana > > If we fail to allocate a new data chunk, we were jumping to the error path > without release the transaction handle we got before. Fix this by always > releasing it before doing the

Re: subvols and parents - how?

On Sat, 2015-12-12 at 03:32 +0100, Christoph Anton Mitterer wrote: > What's still missing now, IMHO, is: > - a guide when one should make subvole (e.g. keeping things on the > root > fs together, unless it's separate like /var/www is usually, but > /var/lib typically "corresponds" to a state of