Re: How to fix errors that check --mode lomem finds, but --mode normal doesn't?

On Thu, Jun 22, 2017 at 12:08:44PM +0800, Qu Wenruo wrote: > > On Thu, Jun 22, 2017 at 10:22:57AM +0800, Qu Wenruo wrote: > > > > gargamel:~# btrfs check -p --mode lowmem /dev/mapper/dshelf2 > > > > Checking filesystem on /dev/mapper/dshelf2 > > > > UUID: 85441c59-ad11-4b25-b1fe-974f9e4acede > >

Re: Stability status of btrfs-convert...

At 06/22/2017 07:31 PM, Austin S. Hemmelgarn wrote: On 2017-06-22 05:37, Shyam Prasad N wrote: Hi, I'm planning to use the btrfs-convert tool to convert production data in ext4 filesystem into btrfs. What is the stability status of this feature? As per the below link, this tool is not in

[PATCH 3/4] btrfs: Add zstd support

Add zstd compression and decompression support to BtrFS. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression, approaching lzo speeds. I benchmarked btrfs with zstd compression against no compression, lzo compression, and zlib

[PATCH 4/4] squashfs: Add zstd support

Add zstd compression and decompression support to SquashFS. zstd is a great fit for SquashFS because it can compress at ratios approaching xz, while decompressing twice as fast as zlib. For SquashFS in particular, it can decompress as fast as lzo and lz4. It also has the flexibility to turn down

[PATCH 1/4] lib: Add xxhash module

Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an extremely fast non-cryptographic hash algorithm for checksumming. The zstd compression and decompression modules added in the next patch require xxhash. I extracted it out from zstd since it is useful on its own. I copied the code

Re: [RFC PATCH 0/4] Support for metadata specific accounting

On Thu, Jun 22, 2017 at 05:23:20PM +0300, Nikolay Borisov wrote: > Hello, > > This series is a report of Josef's original posting [1]. I've included > fine-grained changelog in each patch with my changes. Basically, I've forward > ported it to 4.12-rc6 and tried incorporating the feedback which

[PATCH 1/4] remove mapping from balance_dirty_pages*()

From: Josef Bacik The only reason we pass in the mapping is to get the inode in order to see if writeback cgroups is enabled, and even then it only checks the bdi and a super block flag. balance_dirty_pages() doesn't even use the mapping. Since balance_dirty_pages*() works on a

[RFC PATCH 0/4] Support for metadata specific accounting

Hello, This series is a report of Josef's original posting [1]. I've included fine-grained changelog in each patch with my changes. Basically, I've forward ported it to 4.12-rc6 and tried incorporating the feedback which was given to every individual patch (I've included link with that

[PATCH 3/4] writeback: add counters for metadata usage

From: Josef Bacik Btrfs has no bounds except memory on the amount of dirty memory that we have in use for metadata. Historically we have used a special inode so we could take advantage of the balance_dirty_pages throttling that comes with using pagecache. However as we'd like to

[PATCH 2/4] writeback: convert WB_WRITTEN/WB_DIRITED counters to bytes

From: Josef Bacik These are counters that constantly go up in order to do bandwidth calculations. It isn't important what the units are in, as long as they are consistent between the two of them, so convert them to count bytes written/dirtied, and allow the metadata accounting

[PATCH 4/4] writeback: introduce super_operations->write_metadata

From: Josef Bacik Now that we have metadata counters in the VM, we need to provide a way to kick writeback on dirty metadata. Introduce super_operations->write_metadata. This allows file systems to deal with writing back any dirty metadata we need based on the writeback needs of

[PATCH v2 2/2] btrfs: Simplify math in should_alloc chunk

From: Nikolay Borisov Currently should_alloc_chunk uses ->total_bytes - ->bytes_readonly to signify the total amount of bytes in this space info. However, given Jeff's patch which adds bytes_pinned and bytes_may_use to the calculation of num_allocated it becomes a lot more

[PATCH v2 1/2] btrfs: account for pinned bytes in should_alloc_chunk

From: Jeff Mahoney In a heavy write scenario, we can end up with a large number of pinned bytes. This can translate into (very) premature ENOSPC because pinned bytes must be accounted for when allowing a reservation but aren't accounted for when deciding whether to create a new

[PATCH 0/11 v1] Fix inheritance of SGID in presence of default ACLs

Hello, this patch set fixes a problem introduced by commit 073931017b49 "posix_acl: Clear SGID bit when setting file permissions". The problem is that when new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the

[PATCH 03/11] btrfs: Don't clear SGID when inheriting ACLs

When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to

Re: Stability status of btrfs-convert...

On Thu, Jun 22, 2017 at 06:48:53PM +0530, Shyam Prasad N wrote: > The disks that I need to convert could have anywhere from a few GBs to a > maximum of 4 TB. I plan to add the btrfs-convert to a script which does a > software upgrade. (The older version used to store data in extra, we've > moved

Re: Stability status of btrfs-convert...

On Thu, Jun 22, 2017 at 03:07:14PM +0530, Shyam Prasad N wrote: > I'm planning to use the btrfs-convert tool to convert production data > in ext4 filesystem into btrfs. > What is the stability status of this feature? It has been recently (btrfs-progs 4.6) rewritten nearly from scratch. This was

Re: Stability status of btrfs-convert...

>Is this tool supported, at least? Can I use this tool as a part of >software upgrade to change the data filesystem to btrfs? Yes its supported. If your existing FS is too large (>22TB) we have a bug for it https://bugzilla.kernel.org/show_bug.cgi?id=194795 AFAIK, there are quite number of

Re: Stability status of btrfs-convert...

On 2017-06-22 05:37, Shyam Prasad N wrote: Hi, I'm planning to use the btrfs-convert tool to convert production data in ext4 filesystem into btrfs. What is the stability status of this feature? As per the below link, this tool is not in frequent use in latest linux kernels.

Stability status of btrfs-convert...

Hi, I'm planning to use the btrfs-convert tool to convert production data in ext4 filesystem into btrfs. What is the stability status of this feature? As per the below link, this tool is not in frequent use in latest linux kernels. https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

[PATCH v2] btrfs-progs: lowmem check: Fix false alert about file extent interrupt

As Qu mentioned in this thread (https://www.spinics.net/lists/linux-btrfs/msg64469.html), compression can cause regular extent to co-exist with inlined extent. This coexistence makes things confusing. Since it was permitted currently, so fix btrfsck to prevent a bunch of error logs that will make

[PATCH v2] btrfs-progs: Fix 'btrfs device stats --check' cli option

Bug 194961 - btrfs device stats --check does not work https://bugzilla.kernel.org/show_bug.cgi?id=194961 Reported-by: Tomas Thiemel Signed-off-by: Lakshmipathi.G --- cmds-device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/cmds-device.c

[PATCH] btrfs-progs: lowmem check: Fix false alert about file extent interrupt

As Qu mentioned in this thread (https://www.spinics.net/lists/linux-btrfs/msg64469.html), compression can cause regular extent to co-exist with inlined extent. This coexistence makes things confusing. Since it was permitted currently, so fix btrfsck to prevent a bunch of error logs that will make

[PATCH] Fix 'btrfs device stats --check' cli option

Reported by Tomas Thiemel Bug 194961 - btrfs device stats --check does not work --- cmds-device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/cmds-device.c b/cmds-device.c index 5e016a7..4337eb2 100644 --- a/cmds-device.c +++ b/cmds-device.c @@ -400,6 +400,7 @@