Re: ENOSPC while creating snapshot

Chris Murphy posted on Fri, 04 Mar 2016 19:46:34 -0700 as excerpted: > On Fri, Mar 4, 2016 at 4:16 PM, Martin Mlynář wrote: [Mount options line split/wrapped for followup] rw,noatime,nodatasum,nodatacow,ssd,discard,space_cache,

Re: ENOSPC while creating snapshot

On Fri, Mar 4, 2016 at 4:16 PM, Martin Mlynář wrote: (rw,noatime,nodatasum,nodatacow,ssd,discard,space_cache,enospc_debug,commit=900,subvolid=5,subvol=/) >> >> Most likely unrelated but commit time of 15 minutes? Umm, OK why? > > > I'm trying to reduce writes to my ssd. This

Re: ENOSPC while creating snapshot

Roman Mamedov posted on Sat, 05 Mar 2016 03:49:10 +0500 as excerpted: > As you use the nodatacow mount option, this seems to be another case of > http://www.spinics.net/lists/linux-btrfs/msg51276.html > http://www.spinics.net/lists/linux-btrfs/msg51819.html > > and is fixed by

[PATCH 12/12] block: test fallocate for block devices

Now that we're wiring up fallocate's PUNCH_HOLE and ZERO_RANGE features for block devices, add some tests to make sure they work correctly. Signed-off-by: Darrick J. Wong --- common/scsi_debug |6 ++- tests/generic/705 | 65

[PATCH 10/12] xfs: test per-ag allocation accounting during truncate-caused refcountbt expansion

Ensure that refcountbt allocations during truncate operations come from the per-AG reservation and are not charged to the transaction. Reported-by: Christoph Hellwig Signed-off-by: Darrick J. Wong --- tests/xfs/855 | 95

[PATCH 11/12] xfs: remove NOCOW_FL testing from test

Since XFS dropped support for the NOCOW_FL flag, cut it out of the tests. Signed-off-by: Darrick J. Wong --- tests/xfs/132 |5 - tests/xfs/132.out | 20 2 files changed, 25 deletions(-) diff --git a/tests/xfs/132 b/tests/xfs/132

[PATCH 09/12] xfs/122: support rmapxbt

Support the extended rmap btree key structure. Signed-off-by: Darrick J. Wong --- tests/xfs/122.out |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/xfs/122.out b/tests/xfs/122.out index c590166..451871e 100644 --- a/tests/xfs/122.out +++

[PATCH 03/12] reflink: fix fragmentation tests to work on >4k block size filesystems

For tests that only overwrite part of a file, only consider the number of extents in the *rewritten* blocks when deciding if the FS fragmentation performance is satisfactory. (Also slip in a fix for xfs/127 so that it formats correctly when we specify big blocksizes via MKFS_OPTIONS.)

[PATCH 05/12] xfs/206: fix output when mkfs knows about reflink

Signed-off-by: Darrick J. Wong --- tests/xfs/206 |1 + tests/xfs/206.out |2 ++ 2 files changed, 3 insertions(+) diff --git a/tests/xfs/206 b/tests/xfs/206 index 0f5d97d..24e690a 100755 --- a/tests/xfs/206 +++ b/tests/xfs/206 @@ -80,6 +80,7 @@ mkfs_filter()

[PATCH 04/12] xfs/23[3-6]: don't source common/xfs, it doesn't exist

Don't source common/xfs, since it doesn't (yet) exist. Signed-off-by: Darrick J. Wong --- tests/xfs/233 |1 - tests/xfs/234 |1 - tests/xfs/235 |1 - tests/xfs/236 |1 - 4 files changed, 4 deletions(-) diff --git a/tests/xfs/233 b/tests/xfs/233 index

[PATCH 07/12] xfs/073: fix output

Signed-off-by: Darrick J. Wong --- tests/xfs/073.out |3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/xfs/073.out b/tests/xfs/073.out index 3f27467..fb035cb 100644 --- a/tests/xfs/073.out +++ b/tests/xfs/073.out @@ -1,4 +1,7 @@ QA output created by 073

[PATCH 06/12] xfs/030: fix output on newer filesystems

Signed-off-by: Darrick J. Wong --- tests/xfs/030 |5 - tests/xfs/030.out.linux |2 ++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/tests/xfs/030 b/tests/xfs/030 index 4cb1524..33c906c 100755 --- a/tests/xfs/030 +++ b/tests/xfs/030

[PATCH 08/12] xfs/122: define _GNU_SOURCE when compiling test program

This makes it so we don't get warnings about off64_t not being defined when compiling the test program. Signed-off-by: Darrick J. Wong --- tests/xfs/122 |1 + 1 file changed, 1 insertion(+) diff --git a/tests/xfs/122 b/tests/xfs/122 index 758cb50..dc28c56 100755

[PATCH 02/12] xfs: test copy-on-write leftover recovery

Test recovery of CoW leftovers in xfs_repair. Signed-off-by: Darrick J. Wong --- tests/xfs/853 | 179 + tests/xfs/853.out | 13 tests/xfs/854 | 180 +

[PATCH v5 00/12] xfstests: minor fixes for the reflink/dedupe tests

This is a patch set for xfstests, associated with the fifth revision to a patch series adding reverse mapping and reflink to XFS. Patches 1, 3-9, and 11 are bug fixes to existing reflink tests. Patches 2 and 10 add a few more XFS-specific reflink tests to ensure that we get the CoW and metadata

[PATCH 01/12] xfs/207: fix golden output to match FS_IOC_FSSETXATTR hoist

Signed-off-by: Darrick J. Wong --- tests/xfs/207.out |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/xfs/207.out b/tests/xfs/207.out index 14eede4..434b8d9 100644 --- a/tests/xfs/207.out +++ b/tests/xfs/207.out @@ -3,7 +3,7 @@ Format

Re: ENOSPC while creating snapshot

On Fri, 04 Mar 2016 22:10:57 +0100 ne...@smoula.net wrote: > Hello, > > I'm encountering weird enospc problem while writing to filesystem and > creating snapshot at a same time: > > Steps to reproduce: > > start writing data to filesystem: > > # LC_ALL=C dd if=/dev/zero of=/foobar > dd:

Re: ENOSPC while creating snapshot

On Fri, Mar 4, 2016 at 2:10 PM, wrote: > Hello, > > I'm encountering weird enospc problem while writing to filesystem and > creating snapshot at a same time: > > Steps to reproduce: > > start writing data to filesystem: > > # LC_ALL=C dd if=/dev/zero of=/foobar > dd: writing to

ENOSPC while creating snapshot

Hello, I'm encountering weird enospc problem while writing to filesystem and creating snapshot at a same time: Steps to reproduce: start writing data to filesystem: # LC_ALL=C dd if=/dev/zero of=/foobar dd: writing to '/foobar': No space left on device 3003803+0 records in 3003802+0 records

[PATCH] btrfs: Fix misspellings in comments.

Signed-off-by: Adam Buchbinder --- fs/btrfs/check-integrity.c | 2 +- fs/btrfs/ctree.h | 10 +- fs/btrfs/dev-replace.c | 2 +- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 2 +- fs/btrfs/extent_map.c | 4 ++--

Re: balance hangs and starts again on reboot

On Fri, Mar 4, 2016 at 10:31 AM, Marc Haber wrote: > Hi, > > I have another btrfs on the same host that has no the no space left on > device balance issue, but on another disk. On this btrfs, it seems > like a balance process is stuck, with a lot of hanging kernel >

Re: [PATCH] btrfs-progs: libbtrfs: remove max/min macros from API

On Fri, Mar 04, 2016 at 02:46:11PM +0100, Ondrej Kozina wrote: > kerncompat.h header file is part of libbtrfs API. min/max macros cause > conflict while building projects dependant on libbtrfs. Moving those > macros to btrfs-progs internal header file fixes the conflict. > > Signed-of-by: Ondrej

Re: [PATCH] remove max/min macros from libbtrfs API

On Fri, Mar 04, 2016 at 02:46:10PM +0100, Ondrej Kozina wrote: > Hello btrfs-progs, > > can we move the min/max macros away from libbtrfs public API? This may cause > conflict > while compiling i.e. snapper with gcc 6.0 (aka with -std=gnu++14). The thing > is I don't see a point why those macros

[GIT PULL] Btrfs

Hi Linus, We've got a fix in my for-linus-4.5 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.5 Filipe nailed down a problem where tree log replay would do some work that orphan code wasn't expecting to be done yet, leading to BUG_ON. Filipe Manana (1)

Re: balance hangs and starts again on reboot

On 03/04/16 18:31, Marc Haber wrote: > I have another btrfs on the same host that has no the no space left on > device balance issue, but on another disk. On this btrfs, it seems > like a balance process is stuck, with a lot of hanging kernel > threads. After a reboot, when I mount the filesystem,

balance hangs and starts again on reboot

Hi, I have another btrfs on the same host that has no the no space left on device balance issue, but on another disk. On this btrfs, it seems like a balance process is stuck, with a lot of hanging kernel threads. After a reboot, when I mount the filesystem, the balance immediately starts again.

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

Looks like the transaction abort ends up causing the no space, if that's at all helpful. Lot's of free space seems to be irrelevant. Any chance this will be getting better soon? Seems to happen to me a lot these days, and adding space doesn't change anything. [282713.823416] WARNING: CPU: 4 PID:

[PATCH] remove max/min macros from libbtrfs API

Hello btrfs-progs, can we move the min/max macros away from libbtrfs public API? This may cause conflict while compiling i.e. snapper with gcc 6.0 (aka with -std=gnu++14). The thing is I don't see a point why those macros should be kept in kerncompat.h at all. Such macros are used solely in

[PATCH] btrfs-progs: libbtrfs: remove max/min macros from API

kerncompat.h header file is part of libbtrfs API. min/max macros cause conflict while building projects dependant on libbtrfs. Moving those macros to btrfs-progs internal header file fixes the conflict. Signed-of-by: Ondrej Kozina --- backref.c | 1 + ctree.c

Re: incomplete conversion to RAID1?

Nicholas D Steeves posted on Thu, 03 Mar 2016 16:21:53 -0500 as excerpted: > Hi Duncan, > >> Of course either way assumes you don't run into some bug that will >> prevent removal of that chunk, perhaps exactly the same one that kept >> it from being removed during the normal raid1 conversion.

Re: Again, no space left on device while rebalancing and recipe doesnt work

On Fri, Mar 04, 2016 at 12:31:44PM +, Duncan wrote: > Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted: > > > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>: > >> > >> You're issue isn't the same, because all your space was allocated, > >> leaving only 1 MiB

Re: Again, no space left on device while rebalancing and recipe doesnt work

Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted: > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>: >> >> You're issue isn't the same, because all your space was allocated, >> leaving only 1 MiB unallocated, which isn't normally enough to allocate >> a new chunk to

Re: [RFC] Experimental btrfs encryption

On 2016-03-01 23:48, Anand Jain wrote: On 03/02/2016 02:23 AM, Chris Mason wrote: On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote: On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote: We'll definitely move in line with the common API over time. Thanks Anand for

Re: Stray 4k extents with slow buffered writes

Holger Hoffstätte posted on Thu, 03 Mar 2016 20:53:57 +0100 as excerpted: > It changes things because you likely have a higher value set for > vm/dirty_expire_centisecs or dirty_bytes explicitly configured; I have > it set to 1000 (10s) to prevent large writebacks from choking > everything. > The

Re: [PATCH] Show a warning message if one of highest objectid reaches its max value

On Fri, Mar 4, 2016 at 2:37 AM, Satoru Takeuchi wrote: > - It's better to show a warning message for the exceptional case > that one of highest objectid (in most case, inode number) > reaches its max value, BTRFS_LAST_FREE_OBJECTID. Show this > message only

Re: how many chunk trees and extent trees present

On Fri, Mar 04, 2016 at 10:58:15AM +0800, Anand Jain wrote: > > > On 04/18/2015 01:29 AM, David Sterba wrote: > > On Fri, Apr 17, 2015 at 09:19:11AM +, Hugo Mills wrote: > >>> In, some article i read that future there will be more chunk tree/ extent > >>> tree for single btrfs. Is this true.

Re: btrfs_get_token_64() alignment problem on ARM (was: Re: DWord alignment on ARMv7)

On Fri, Mar 04, 2016 at 09:01:44AM +0100, Marc Kleine-Budde wrote: > Hello, > > On 03/04/2016 12:54 AM, Will Deacon wrote: > > Hi Marc, > > > > On Thu, Mar 03, 2016 at 11:27:11PM +0100, Marc Kleine-Budde wrote: > >> I'm using btrfs on am ARMv7 and it turns out, that the kernel has to > >> fixup

btrfs_get_token_64() alignment problem on ARM (was: Re: DWord alignment on ARMv7)

Hello, On 03/04/2016 12:54 AM, Will Deacon wrote: > Hi Marc, > > On Thu, Mar 03, 2016 at 11:27:11PM +0100, Marc Kleine-Budde wrote: >> I'm using btrfs on am ARMv7 and it turns out, that the kernel has to >> fixup a lot of kernel originated alignment issues. >> >> See /proc/cpu/alignment (~4h of