similar to: btrfs-cleaner Blocked on xfstests 068

Hello, (this is a recap of yesterday''s discussion on BTRFS IRC, also to save relevant pastes before pastebins expire) I have my /home on btrfs; a cronjob makes one snapshot every 30 minutes; these snapshots are kept for 24-48 hours, then deleted in batches. This is a 16K Leaf/Node BTRFS on top of mdadm RAID1. As system uptime approached 2 weeks, I started noticing that the free space

Hi, I got a panic when running CentOS-6.5: crash> bt PID: 106074 TASK: ffff8839c1e32ae0 CPU: 4 COMMAND: "flushd4[cbd-sd-" #0 [ffff8839c2a91900] machine_kexec at ffffffff81038fa9 #1 [ffff8839c2a91960] crash_kexec at ffffffff810c5992 #2 [ffff8839c2a91a30] oops_end at ffffffff81515c90 #3 [ffff8839c2a91a60] no_context at ffffffff81049f1b #4 [ffff8839c2a91ab0]

Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the

I''ve been working on running down intermittent ENOSPC issues. I can only seem to replicate ENOSPC errors when running zlib compression. However, I have been seeing similar ENOSPC errors to a lesser extent when playing with the LZ4HC patches. I apologize for not following up on this sooner, but I had drifted away from using zlib, and didn''t notice there was still an issue. My

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

I''ve cloned: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git When I build I get compile errors trying to build dmapi. Do I need to build this? I''ve attached a log of the build (build.log). If I ignore the build error and just go ahead and try to run the tests my first question is, "What do I run?". Looking at the README it looks like I want to run

This is similar to a previous fix I sent. 1 gig makes us do mixed file block groups for btrfs, so these enospc tests will usually fail because we don''t have space for metadata, which is the case for this test. So jack the size up to 1.5gig so that btrfs can do its normal thing and pass the test. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- tests/generic/256 |

Currently we can specify the testing filesytems like ''check -xfs'', but btrfs is not support in this kind of command option. Add the option ''check -btrfs'' support. Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> --- check | 2 ++ 1 file changed, 2 insertions(+) diff --git a/check b/check index ff8fbcf..9c40615 100755 --- a/check +++ b/check @@

Not sure how this happened, but filter.btrfs including itself leads to immense sadness for any file that includes it. (I got a segfault when I tried to run 307) Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- diff --git a/common/filter.btrfs b/common/filter.btrfs index b1aa733..99d04a6 100644 --- a/common/filter.btrfs +++ b/common/filter.btrfs @@ -1,7 +1,5 @@ # Filters for btrfs

I''m not sure how the numbering is supposed to work now that we''ve split everything out so I''m just going with the next number in the directory. This is a regression test for btrfs send, we had a problem where we''d try to send a file that had been deleted in the source snapshot. This is just to make sure we don''t have the same problem in the future.

Btrfs had some issues with fsync()''ing directories and fsync()''ing after renames. These three new tests cover the 3 different issues we were seeing. This breaks out the dmflakey stuff into a common helper to be shared between generic/311 and generic/320. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- V1->V2: moved this out into its own test instead of

So if you have a mount command that doesn''t use /etc/mtab then it will spit out a different device for the mounted device. So say we have SCRATCH_DEV_POOL="/dev/sda /dev/sdb /dev/sdc" we will turn this into SCRATCH_DEV="/dev/sda" SCRATCH_DEV_POOL="/dev/sdb /dev/sdc" and then when you mkfs this you do _scratch_mkfs $SCRATCH_DEV_POOL which turns into this

This testscript creates reflinks to files on different subvolumes, overwrites the original files and reflinks, and moves reflinked files between subvolumes. Originally submitted as testcase 302, changes are made based on comments from Eric: http://oss.sgi.com/archives/xfs/2013-03/msg00231.html Two new common/rc functions used in this script (_require_cp_reflink and _verify_reflink) have been

The btrfs-progs tools changed the output: - 100GiB instead of 100GB - The number of spaces was changed Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> --- common/filter | 2 +- common/filter.btrfs | 3 ++- tests/btrfs/006 | 6 +++--- tests/btrfs/006.out | 36 ++++++++++++++++++------------------ 4 files changed, 24 insertions(+), 23 deletions(-) diff --git

This testscript creates reflinks to files on different subvolumes, overwrites the original files and reflinks, and moves reflinked files between subvolumes. Originally submitted as testcase 302, changes are made based on comments from Eric: http://oss.sgi.com/archives/xfs/2013-03/msg00231.html Two new common/rc functions used in this script (_require_cp_reflink and _verify_reflink) have been

Btrfs had some issues with fsync()''ing directories and fsync()''ing after renames. These three new tests cover the 3 different issues we were seeing. This breaks out the dmflakey stuff into a common helper to be shared between generic/311 and generic/321. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- V1->V2: rename test to generic/321 -removed an

I am currently looking at a bug report[1] which is happening when a Xen PVM guest with multiple VCPUs is running a high IO database load (a test script is available in the bug report). In experimenting it seems that this happens (or is getting more likely) when the number of VCPUs is 8 or higher (though I have not tried 6, only 2 and 4), having autogroup enabled seems to make it more likely, too