Re: how to run balance successfully (No space left on device)?

On 2017-09-18 17:20, Tomasz Chmielewski wrote: # df -h /var/lib/lxd FWIW, standard (aka util-linux) df is effectively useless in a situation such as this, as it really doesn't give you the information you need (it can say you have lots of space available, but if btrfs has all of it allocated

Re: [PATCH] btrfs: cleanup btrfs_async_submit_limit to return the final limit value

On 31.10.2017 14:59, Anand Jain wrote: > btrfs_async_submit_limit() would return the q depth to be 256, however > when we are using it we are making it 2/3 times of it. So instead let > the function return the final computed value. > > Signed-off-by: Anand Jain Could

Re: btrfs-subv-backup v0.1b

On 2017-10-31 08:40, Lentes, Bernd wrote: - Am 26. Okt 2017 um 15:32 schrieb Austin S. Hemmelgarn ahferro...@gmail.com: As previously mentioned on the list, I've written up a script to back up BTRFS subvolume structures in regular file-based backups. As of right now, it's still a bit

Re: [PATCH v2 1/2] btrfs: match btrfs_device->mode same as it used for open

On 31.10.2017 04:11, Anand Jain wrote: > > > On 10/30/2017 10:39 PM, David Sterba wrote: >> On Fri, Oct 20, 2017 at 10:07:15PM +0800, Anand Jain wrote: >>> We aren't setting the FMODE_WRITE when initializing btrfs_device >>> structure and when calling blkdev_put, however we are setting it >>>

btrfs-subv-backup v0.3b

A new version of btrfs-subv-backup has just been uploaded to github. Yes, I know I skipped v0.2b, I actually did upload a version v0.2b, I just forgot to post anything about it here... Changes since the last time I posted here: v0.2b: * Updated the LICENSE file so that GitHub properly

[PATCH] btrfs-progs: convert: add missing types header

Build with musl libc needs the sys/types.h header for the dev_t type, since this header is not included indirectly. This fixes the following build failure: In file included from convert/source-fs.c:23:0: ./convert/source-fs.h:112:1: error: unknown type name ‘dev_t’ dev_t decode_dev(u32 dev);

[PATCH] btrfs: cleanup btrfs_async_submit_limit to return the final limit value

btrfs_async_submit_limit() would return the q depth to be 256, however when we are using it we are making it 2/3 times of it. So instead let the function return the final computed value. Signed-off-by: Anand Jain --- fs/btrfs/disk-io.c | 6 -- fs/btrfs/volumes.c | 1 -

Re: btrfs-subv-backup v0.1b

- Am 26. Okt 2017 um 15:32 schrieb Austin S. Hemmelgarn ahferro...@gmail.com: > As previously mentioned on the list, I've written up a script to back up > BTRFS subvolume structures in regular file-based backups. As of right > now, it's still a bit rough around the edges, but it's cleaned

Re: how to run balance successfully (No space left on device)?

On 2017-10-31 23:18, Tomasz Chmielewski wrote: On a different server, however, it failed badly: # time btrfs balance start /srv WARNING: Full balance without filters requested. This operation is very intense and takes potentially very long. It is recommended to use the

[PATCH] btrfs: fix default compression value when set by SETFLAGS ioctl

The current default for the compression file flag is 'zlib', the zstd patch silently changed that to zstd. Though the choice of zlib might not be the best one, we should keep the backward compatibility. The incompat bit for zstd is not set, so this could lead to a filesystem with a zstd

[PATCH 04/11] btrfs: use free_device where opencoded

Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 39 +++ 1 file changed, 11 insertions(+), 28 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 35c546aade83..f206e83d4f52 100644 --- a/fs/btrfs/volumes.c +++

[PATCH 11/11] btrfs: use non-RCU list traversal in write_all_supers callees

We take the fs_devices::device_list_mutex mutex in write_all_supers which will prevent any add/del changes to the device list. Therefore we don't need to use the RCU variant list_for_each_entry_rcu in any of the called functions. Signed-off-by: David Sterba ---

[PATCH 01/11] btrfs: add missing device::flush_bio puts

This fixes potential bio leaks, in several error paths. Unfortunatelly the device structure freeing is opencoded in many places and I missed them when introducing the flush_bio. Most of the time, devices get freed through call_rcu(..., free_device), so it at least it's not that easy to hit the

[PATCH 06/11] btrfs: document device locking

Overview of the main locks protecting various device-related structures. Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 66 ++ 1 file changed, 66 insertions(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index

[PATCH 03/11] btrfs: introduce free_device helper

A helper to free a device and all it's dynamically allocated members, like the rcu_string name or flush_bio. This is going to replace all open coded places. Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 16 ++-- 1 file changed, 14 insertions(+), 2

[PATCH 09/11] btrfs: switch to RCU for device traversal in btrfs_ioctl_dev_info

We don't need to use the mutex as we do not modify the devices nor the list itself and just read some information: does not change during device lifetime: - devid - uuid - name (ie. the path) may change in parallel to the ioctl call, but can lead only to reporting inacurracy: - bytes_used -

[PATCH 10/11] btrfs: switch to RCU for device traversal in btrfs_ioctl_fs_info

We don't need to use the mutex as we do not modify the devices nor the list itself and just read information about device counts. Move copying fsid out of the protected section, not applicable to RCU same as the rest of the retrieved information. Signed-off-by: David Sterba ---

[PATCH 07/11] btrfs: dev_alloc_list is not protected by RCU, use normal list_del

The dev_alloc_list list could be protected by various mutexes, depending on the context. The list tracks devices that can take part of allocating new chunks, so the closest mutex is chunk_mutex. Adding a new device from inside the ADD_DEV ioctl will need device_list_mutex and registering a new

[PATCH 08/11] btrfs: simplify btrfs_close_bdev

Split the conditions a bit. Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 6e45751ed957..3af2a7fd2d05 100644 --- a/fs/btrfs/volumes.c +++

[PATCH 05/11] btrfs: simplify exit paths in btrfs_init_new_device

Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index f206e83d4f52..75aed8ec64bd 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -2344,17 +2344,15

[PATCH 00/11] Device fixes and cleanups

Cleanups for device locking and documentation of the various mutexes. Patch 1 is a bugfix that could be considered for 4.15 as we could leak bios under some rare condition, but so far this hasn't been reported so I don't rate is as critical. David Sterba (11): btrfs: add missing

[PATCH 02/11] btrfs: rename device free rcu helper to free_device_rcu

Make it clear that it is an RCU helper, we want to use the name free_device for a wrapper freeing all device members. Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/volumes.c

Re: Several questions regarding btrfs

On 2017-10-31 12:23, ST wrote: Hello, I've recently learned about btrfs and consider to utilize for my needs. I have several questions in this regard: I manage a dedicated server remotely and have some sort of script that installs an OS from several images. There I can define partitions and

Re: btrfs-subv-backup v0.1b

- On Oct 31, 2017, at 2:59 PM, Austin S. Hemmelgarn ahferro...@gmail.com wrote: >> Hi Austin, >> >> thanks for your effort. What are the minimum prerequesties for kernel and >> btrfsprogs for that script ? >> Do you think it will run on my old SLES 11 SP4 ? > Dependency-wise, it needs: > >

Re: btrfs-subv-backup v0.1b

On 2017-10-31 12:54, Lentes, Bernd wrote: - On Oct 31, 2017, at 2:59 PM, Austin S. Hemmelgarn ahferro...@gmail.com wrote: Hi Austin, thanks for your effort. What are the minimum prerequesties for kernel and btrfsprogs for that script ? Do you think it will run on my old SLES 11 SP4 ?

[PATCH 3/4] btrfs: sink gfp parameter to clear_extent_uptodate

There's only one callsite with GFP_NOFS. Signed-off-by: David Sterba --- fs/btrfs/extent_io.h | 4 ++-- fs/btrfs/inode.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h index bc9ebc858fae..e6987b050964

[PATCH 2/4] btrfs: sink gfp parameter to clear_extent_bit

All callers use GFP_NOFS, we don't have to pass it as an argument. The built-in tests pass GFP_KERNEL, but they run only at module load time and NOFS works there as well. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 10 +- fs/btrfs/extent_io.h

[PATCH 1/4] btrfs: prepare to drop gfp mask parameter from clear_extent_bit

Use __clear_extent_bit directly in case we want to pass unknown gfp flags. Otherwise all clear_extent_bit callers use GFP_NOFS, so we can sink them to the function and reduce argument count, at the cost that __clear_extent_bit has to be exported. Signed-off-by: David Sterba ---

[PATCH 4/4] btrfs: use GFP_KERNEL in btrfs_alloc_inode

This callback is called directly from VFS, no locks are held at the allocation time. Signed-off-by: David Sterba --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 8de8b38ee22f..9ac796f98c9e 100644

[PATCH 0/4] More GFP_NOFS cleanups

David Sterba (4): btrfs: prepare to drop gfp mask parameter from clear_extent_bit btrfs: sink gfp parameter to clear_extent_bit btrfs: sink gfp parameter to clear_extent_uptodate btrfs: use GFP_KERNEL in btrfs_alloc_inode fs/btrfs/extent_io.c | 16

Several questions regarding btrfs

Hello, I've recently learned about btrfs and consider to utilize for my needs. I have several questions in this regard: I manage a dedicated server remotely and have some sort of script that installs an OS from several images. There I can define partitions and their FSs. 1. By default the

Several questions regarding btrfs

Hello, I've recently learned about btrfs and consider to utilize for my needs. I have several questions in this regard: I manage a dedicated server remotely and have some sort of script that installs an OS from several images. There I can define partitions and their FSs. 1. By default the

[PATCH 2/2] Btrfs: fix reported number of inode blocks after buffered append writes

From: Filipe Manana The patch from commit 7e3b975a0f92 ("Btrfs: fix reported number of inode blocks") introduced a regression where if we do a buffered write starting at position equal to or greater than the file's size and then stat(2) the file before writeback is triggered,

Re: btrfs-subv-backup v0.1b

- On Oct 31, 2017, at 6:00 PM, Austin S. Hemmelgarn ahferro...@gmail.com wrote: > Assuming you're careful about how you install it (that is, put it in a > custom prefix that isn't in $PATH), you could always build a local > version of Python. Once you've got that, it's pretty trivial to

Re: Several questions regarding btrfs

On 2017-10-31 14:51, Andrei Borzenkov wrote: 31.10.2017 20:45, Austin S. Hemmelgarn пишет: On 2017-10-31 12:23, ST wrote: Hello, I've recently learned about btrfs and consider to utilize for my needs. I have several questions in this regard: I manage a dedicated server remotely and have some

Re: Several questions regarding btrfs

31.10.2017 20:45, Austin S. Hemmelgarn пишет: > On 2017-10-31 12:23, ST wrote: >> Hello, >> >> I've recently learned about btrfs and consider to utilize for my needs. >> I have several questions in this regard: >> >> I manage a dedicated server remotely and have some sort of script that >>

[PATCH 1/2] Btrfs: use cached state when dirtying pages during buffered write

From: Filipe Manana During a buffered IO write, we can have an extent state that we got when we locked the range (if the range starts at an offset lower than eof), so always pass it to btrfs_dirty_pages() so that setting the delalloc bit in the range does not need to do a full

Re: btrfs-subv-backup v0.1b

On 2017-10-31 15:54, Lentes, Bernd wrote: - On Oct 31, 2017, at 6:00 PM, Austin S. Hemmelgarn ahferro...@gmail.com wrote: Assuming you're careful about how you install it (that is, put it in a custom prefix that isn't in $PATH), you could always build a local version of Python. Once

Re: Several questions regarding btrfs

Thank you very much for such an informative response! On Tue, 2017-10-31 at 13:45 -0400, Austin S. Hemmelgarn wrote: > On 2017-10-31 12:23, ST wrote: > > Hello, > > > > I've recently learned about btrfs and consider to utilize for my needs. > > I have several questions in this regard: > > > >

Re: [PATCH] btrfs: fix default compression value when set by SETFLAGS ioctl

On 10/31/17, 9:48 AM, "David Sterba" wrote: > The current default for the compression file flag is 'zlib', the zstd > patch silently changed that to zstd. Though the choice of zlib might not > be the best one, we should keep the backward compatibility. Sorry about that, I

Re: [PATCH] Btrfs: bail out gracefully rather than BUG_ON

On 30.10.2017 19:14, Liu Bo wrote: > If a file's DIR_ITEM key is invalid (due to memory errors) and gets > written to disk, a future lookup_path can end up with kernel panic due > to BUG_ON(). > > This gets rid of the BUG_ON(), meanwhile output the corrupted key and > return ENOENT if it's

Re: defragmenting best practice?

I'm following up on all the suggestions regarding Firefox performance on BTRFS. I have time to make these changes now, but I am having trouble figuring out what to do. The constraints are: 1. BTRFS snapshots have proven to be too useful (and too important to our overall IT approach) to forego. 2.

Re: [PATCH] Btrfs: bail out gracefully rather than BUG_ON

On Tue, Oct 31, 2017 at 10:23:30PM +0200, Nikolay Borisov wrote: > > > On 30.10.2017 19:14, Liu Bo wrote: > > If a file's DIR_ITEM key is invalid (due to memory errors) and gets > > written to disk, a future lookup_path can end up with kernel panic due > > to BUG_ON(). > > > > This gets rid of

Re: defragmenting best practice?

> I'm following up on all the suggestions regarding Firefox performance > on BTRFS. [ ... ] I haven't read that yet, so maybe I am missing something, but I use Firefox with Btrfs all the time and I haven't got issues. [ ... ] > 1. BTRFS snapshots have proven to be too useful (and too important

[RFC PATCH 1/3] btrfs-progs: Add EXEC parameter in Makefile

When EXEC parameter is set, do not build this tool. run the test tool with a given path.(/usr/bin, /usr/local/bin) Signed-off-by: Gu Jinxiang --- Makefile| 32 +++- tests/README.md | 10 ++ 2 files changed, 41 insertions(+), 1

[RFC PATCH 3/3] btrfs-progs: Add support for running tools with given path(EXEC)

Modify script of every test case to use executable file of the given path(EXEC), except btrfs-corrupt-block and fssum, because they are internal tools and will not be installed. Signed-off-by: Gu Jinxiang --- tests/cli-tests/001-btrfs/test.sh | 20

[RFC PATCH 0/3] btrfs-progs: Add support for running the tools from

Add support for running the tools from a given path (for example,/usr/bin) by setting $EXEC while running tests. Achieved: Specify the location of binary and run test like this: $ make EXEC=/usr/bin/ test Not Achieved: Can not run make in tests/ directory. Because test-misc depends on fssum

[RFC PATCH 2/3] btrfs-progs: Set EXEC to TOP when it not be defined

Use EXEC instead of TOP when judge whether where is executable files. And set EXEC to TOP when it is not defined in top level test script. Signed-off-by: Gu Jinxiang --- tests/cli-tests.sh | 2 ++ tests/common | 18 -- tests/convert-tests.sh |

Re: [PATCH v2] btrfs-progs: print-tree: Enehance uuid item print

On 31.10.2017 10:28, Qu Wenruo wrote: > For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the > key objectid and key offset is just half of the UUID. > > However we just print the key as %llu, which is converted from little > endian, not byte order for UUID, nor the

[PATCH 1/2] btrfs-progs: Remove unused parameter trans

Some parameter of trans is not used indeed. Let's remove them. Signed-off-by: Gu Jinxiang --- cmds-check.c | 9 - ctree.h | 3 +-- extent-tree.c | 18 -- 3 files changed, 13 insertions(+), 17 deletions(-) diff --git a/cmds-check.c

[PATCH 2/2] btrfs-progs: Remove unused variable

Some variable is never used. Remove them. Signed-off-by: Gu Jinxiang --- Android.mk | 1 - Makefile | 2 -- 2 files changed, 3 deletions(-) diff --git a/Android.mk b/Android.mk index 958b8bd7..de71a5d1 100644 --- a/Android.mk +++ b/Android.mk @@ -38,7 +38,6 @@

[PATCH v2] btrfs-progs: print-tree: Enehance uuid item print

For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the key objectid and key offset is just half of the UUID. However we just print the key as %llu, which is converted from little endian, not byte order for UUID, nor the traditional 36 bytes human readable uuid format. Although

[PATCH 0/3] add_qgroup/update_qgroup/__qgroup_search cleanup

Patch 1 just remove the redundant function add_qgroup. Patch 2 separate QGROUP_INFO/QGROUP_LIMIT/QGROUP_RELATION process from the update_qgroup. Patch 3 mainly the coding style adjustment. Lu Fengqi (3): btrfs-progs: qgroup: cleanup the redundant function add_qgroup btrfs-progs: qgroup: split

[PATCH 2/3] btrfs-progs: qgroup: split update_qgroup to reduce arguments

The function update_qgroup has too many arguments that are too difficult to use. Therefore, split it to update_qgroup_info, update_qgroup_limit, update_qgroup_relation. Signed-off-by: Lu Fengqi --- qgroup.c | 163

[PATCH 3/3] btrfs-progs: qgroup: cleanup __qgroup_search, no functional change

1. Use goto instead of while (1) to reduce the level of indentation 2. Replace the if statement with the switch statement 3. move the BTRFS_IOC_TREE_SEARCH ioctl error handler to __qgroup_search Signed-off-by: Lu Fengqi --- cmds-qgroup.c | 4 -- qgroup.c | 152

[PATCH 1/3] btrfs-progs: qgroup: cleanup the redundant function add_qgroup

There are reusable parts between update_qgroup and add_qgroup. So introduce the function get_or_add_qgroup and use update_qgroup instead of add_qgroup. No functional changes. Signed-off-by: Lu Fengqi --- qgroup.c | 119

Re: [PATCH] btrfs-progs: print-tree: Enehance uuid item print

On 2017年10月31日 15:15, Nikolay Borisov wrote: > > > On 31.10.2017 06:03, Qu Wenruo wrote: >> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the >> key objectid and key offset are just half of the UUID. >> >> However we just print the key as %llu, which is converted from

Re: [PATCH] btrfs-progs: print-tree: Enehance uuid item print

On 31.10.2017 09:15, Nikolay Borisov wrote: > > > On 31.10.2017 06:03, Qu Wenruo wrote: >> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the >> key objectid and key offset are just half of the UUID. >> >> However we just print the key as %llu, which is converted from

Re: [PATCH] btrfs-progs: print-tree: Enehance uuid item print

On 2017年10月31日 15:29, Nikolay Borisov wrote: > > > On 31.10.2017 09:15, Nikolay Borisov wrote: >> >> >> On 31.10.2017 06:03, Qu Wenruo wrote: >>> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the >>> key objectid and key offset are just half of the UUID. >>> >>> However

Re: [PATCH] btrfs-progs: print-tree: Enehance uuid item print

On 2017年10月31日 15:41, Nikolay Borisov wrote: > > > On 31.10.2017 09:35, Qu Wenruo wrote: >> >> >> On 2017年10月31日 15:29, Nikolay Borisov wrote: >>> >>> >>> On 31.10.2017 09:15, Nikolay Borisov wrote: On 31.10.2017 06:03, Qu Wenruo wrote: > For key type BTRFS_UUID_KEY_SUBVOL

Re: [PATCH] btrfs-progs: print-tree: Enehance uuid item print

On 31.10.2017 06:03, Qu Wenruo wrote: > For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the > key objectid and key offset are just half of the UUID. > > However we just print the key as %llu, which is converted from little > endian, not byte order for UUID, nor the

Re: [PATCH] btrfs-progs: print-tree: Enehance uuid item print

On 31.10.2017 09:35, Qu Wenruo wrote: > > > On 2017年10月31日 15:29, Nikolay Borisov wrote: >> >> >> On 31.10.2017 09:15, Nikolay Borisov wrote: >>> >>> >>> On 31.10.2017 06:03, Qu Wenruo wrote: For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the key objectid and

[PATCH 1/2] btrfs-progs: test/fsck: Introduce test images containing tree reloc tree

Tree reloc tree is a special tree with very short life spawn. It acts as a special snapshot for any tree, with related nodes/leaves or EXTENT_DATA modified to point to new position. Considering the short life spawn and its specialness, it should be quite reasonable to keep them as both corner

[PATCH] btrfs: Don't generate UUID for non-fs tree

btrfs_create_tree() will unconditionally generate UUID for any root. So for quota tree and data reloc tree created by kernel, they will have unique UUIDs. However UUID in root item is only referred by UUID tree, which only records UUID for fs trees. This makes unique UUIDs for quota/data reloc

[PATCH 2/2] btrfs-progs: print-tree: Print offset as tree objectid

For case like tree reloc trees and subvolume trees, their key offset is the tree id. For case like tree treloc tree for data reloc tree, The key will be outputted as: (TREE_RELOC ROOT_ITEM 18446744073709551607) The minus number is long and even guys with real engineer brains can't easily get the

Re: [PATCH v2] btrfs-progs: print-tree: Enehance uuid item print

On 2017年10月31日 18:27, Nikolay Borisov wrote: > > > On 31.10.2017 12:09, Qu Wenruo wrote: >> >> >> On 2017年10月31日 16:47, Nikolay Borisov wrote: >>> >>> >>> On 31.10.2017 10:28, Qu Wenruo wrote: For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the key objectid and

Re: [PATCH v2] btrfs-progs: print-tree: Enehance uuid item print

On 2017年10月31日 16:47, Nikolay Borisov wrote: > > > On 31.10.2017 10:28, Qu Wenruo wrote: >> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the >> key objectid and key offset is just half of the UUID. >> >> However we just print the key as %llu, which is converted from

Re: [PATCH v2] btrfs-progs: print-tree: Enehance uuid item print

On 31.10.2017 12:09, Qu Wenruo wrote: > > > On 2017年10月31日 16:47, Nikolay Borisov wrote: >> >> >> On 31.10.2017 10:28, Qu Wenruo wrote: >>> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the >>> key objectid and key offset is just half of the UUID. >>> >>> However we just

Re: [RFC PATCH 0/3] btrfs-progs: Add support for running the tools from

On 2017年10月31日 16:43, Gu Jinxiang wrote: > Add support for running the tools from a given path > (for example,/usr/bin) by setting $EXEC while running tests. > > Achieved: > Specify the location of binary and run test like this: > $ make EXEC=/usr/bin/ test Any special reason to test system

Re: Problem with file system

On 2017-10-31 01:57, Marat Khalili wrote: On 31/10/17 00:37, Chris Murphy wrote: But off hand it sounds like hardware was sabotaging the expected write ordering. How to test a given hardware setup for that, I think, is really overdue. It affects literally every file system, and Linux storage

Re: defragmenting best practice?

On Tue, Oct 31, 2017 at 7:06 PM, Peter Grandi wrote: > > Also nothing forces you to defragment a whole filesystem, you > can just defragment individual files or directories by using > 'find' with it. Thanks for that info. When defragmenting individual files on a

[PATCH v4 2/4] btrfs-progs: test/common: Introduce run_mustfail_stdout

For later test case which needs info from stderr. Signed-off-by: Qu Wenruo --- tests/common | 52 1 file changed, 52 insertions(+) diff --git a/tests/common b/tests/common index dec090fe5849..977bade201a6 100644 ---

[PATCH v4 0/4] mkfs: Fix minimal device check so that reported

Original reported by Wesley AC: https://github.com/kdave/btrfs-progs/issues/70 Fix it by taking data/meta profile and minimal chunk size into consideration. Also introduce a test case for that. Changelog: v2: Refactor test_minimum_size() to take @min_dev_size directly. Refactor patch

[PATCH v4 3/4] btrfs-progs: test/common: Enhance prepare_test_dev to reset device size

So prepare_test_dev() can be called several times in one test case, to test different device sizes. Signed-off-by: Qu Wenruo --- tests/common | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tests/common b/tests/common index 977bade201a6..63750dbfeffe

Re: Data and metadata extent allocators [1/2]: Recap: The data story

On 10/28/2017 02:12 AM, Qu Wenruo wrote: > > On 2017年10月28日 02:17, Hans van Kranenburg wrote: >> Hi, >> >> This is a followup to my previous threads named "About free space >> fragmentation, metadata write amplification and (no)ssd" [0] and >> "Experiences with metadata balance/convert" [1],

[PATCH v4 4/4] btrfs-progs: test/mkfs: Test if the minimal device size is valid

New test case to test if the minimal device size given by "mkfs.btrfs" failure case is valid. Signed-off-by: Qu Wenruo --- tests/mkfs-tests/010-small-image/test.sh | 49 1 file changed, 49 insertions(+) create mode 100755

[PATCH v4 1/4] btrfs-progs: mkfs: Enhance minimal device size calculation to fix mkfs failure on small file

Since commit c11e36a29e84 ("Btrfs-progs: Do not force mixed block group creation unless '-M' option is specified"), mkfs no longer use mixed block group unless specified manually. This breaks the minimal device size calculation, which only considered mixed block group use case. This patch

RE: [RFC PATCH 0/3] btrfs-progs: Add support for running the tools from

> -Original Message- > From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] > Sent: Tuesday, October 31, 2017 6:36 PM > To: Gu, Jinxiang/顾 金香 ; linux-btrfs@vger.kernel.org > Cc: dste...@suse.cz > Subject: Re: [RFC PATCH 0/3] btrfs-progs: Add support for running the tools

Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)

On Wed, 1 Nov 2017 01:00:08 -0400 Dave wrote: > To reconcile those conflicting goals, the only idea I have come up > with so far is to use btrfs send-receive to perform incremental > backups as described here: > https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

Need help with incremental backup strategy (snapshots, defragmentingt & performance)

Our use case requires snapshots. btrfs snapshots are best solution we have found for our requirements, and over the last year snapshots have proven their value to us. (For this discussion I am considering both the "root" volume and the "home" volume on a typical desktop workstation. Also, all