Re: [PATCH preview] btrfs: allow to set compression level for zlib

On 8/4/17, 6:27 PM, "Adam Borowski" wrote: > On Fri, Aug 04, 2017 at 09:51:44PM +, Nick Terrell wrote: > > On 07/25/2017 01:29 AM, David Sterba wrote: > > > Preliminary support for setting compression level for zlib, the > > > following works: > > > > Thanks for working

Re: [PATCH preview] btrfs: allow to set compression level for zlib

On Fri, Aug 04, 2017 at 09:51:44PM +, Nick Terrell wrote: > On 07/25/2017 01:29 AM, David Sterba wrote: > > Preliminary support for setting compression level for zlib, the > > following works: > > Thanks for working on this, I think it is a great feature. > I have a few comments relating to

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

Hi Qu, On Fri, Aug 4, 2017 at 10:05 PM, Qu Wenruo wrote: > > > On 2017年08月02日 16:38, Brendan Hide wrote: >> >> The title seems alarmist to me - and I suspect it is going to be >> misconstrued. :-/ >> >> From the release notes at >>

Re: [PATCH v4 4/5] squashfs: Add zstd support

Signed-off-by: Sean Purcell On Fri, Aug 4, 2017 at 4:19 PM, Nick Terrell wrote: > 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

Re: [PATCH v4 4/5] squashfs: Add zstd support

On 8/4/17, 3:10 PM, "linus...@gmail.com on behalf of Linus Torvalds" wrote: > On Fri, Aug 4, 2017 at 1:19 PM, Nick Terrell wrote: > > > > This patch was written by Sean Purcell , but I will be > >

Re: [PATCH v4 4/5] squashfs: Add zstd support

On Fri, Aug 4, 2017 at 1:19 PM, Nick Terrell wrote: > > This patch was written by Sean Purcell , but I will be > taking over the submission process. Please, if so, get Sean's sign-off, and also make sure that the patch gets submitted with From: Sean Purcell

Re: [PATCH preview] btrfs: allow to set compression level for zlib

On 07/25/2017 01:29 AM, David Sterba wrote: > Preliminary support for setting compression level for zlib, the > following works: Thanks for working on this, I think it is a great feature. I have a few comments relating to how it would work with zstd. > > $ mount -o compess=zlib

Re: please include 17024ad0a0fd ("Btrfs: fix early ENOSPC due to delalloc") to 4.12 stable

On Fri, Aug 04, 2017 at 11:25:14PM +0300, Nikolay Borisov wrote: > Hello, > > I'd like to aforementioned patch to be applied to stable 4.9/4.12. The > attached backport applies cleanly to both of them. Thanks, I'll queue it up after this next release happens. greg k-h -- To unsubscribe from

[PATCH v4 5/5] crypto: Add zstd support

Adds zstd support to crypto and scompress. Only supports the default level. Signed-off-by: Nick Terrell --- crypto/Kconfig | 9 ++ crypto/Makefile | 1 + crypto/testmgr.c | 10 +++ crypto/testmgr.h | 71 +++ crypto/zstd.c| 265

[PATCH v4 4/5] 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

please include 17024ad0a0fd ("Btrfs: fix early ENOSPC due to delalloc") to 4.12 stable

Hello, I'd like to aforementioned patch to be applied to stable 4.9/4.12. The attached backport applies cleanly to both of them. >From 278e5d0839f4ecc6d7bfb7a95cb735b9034e8315 Mon Sep 17 00:00:00 2001 From: Omar Sandoval Date: Thu, 20 Jul 2017 15:10:35 -0700 Subject: [PATCH]

[PATCH v4 3/5] 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 v4 1/5] 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

[PATCH v4 0/5] Add xxhash and zstd modules

Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch has relevant summaries, benchmarks, and tests. Best, Nick Terrell Changelog: v1 -> v2: - Make pointer in lib/xxhash.c:394 non-const (1/5) - Use

Re: FAILED: patch "[PATCH] Btrfs: fix early ENOSPC due to delalloc" failed to apply to 4.12-stable tree

Hey. Could someone of the devs put some attention on this...? Thanks, Chris :-) On Mon, 2017-07-31 at 18:06 -0700, gre...@linuxfoundation.org wrote: > The patch below does not apply to the 4.12-stable tree. > If someone wants it applied there, or to any other stable or longterm > tree, then

Re: Massive loss of disk space

On 2017-08-04 10:45, Goffredo Baroncelli wrote: On 2017-08-03 19:23, Austin S. Hemmelgarn wrote: On 2017-08-03 12:37, Goffredo Baroncelli wrote: On 2017-08-03 13:39, Austin S. Hemmelgarn wrote: [...] Also, as I said below, _THIS WORKS ON ZFS_. That immediately means that a CoW filesystem

Re: Massive loss of disk space

On 2017-08-03 19:23, Austin S. Hemmelgarn wrote: > On 2017-08-03 12:37, Goffredo Baroncelli wrote: >> On 2017-08-03 13:39, Austin S. Hemmelgarn wrote: [...] >>> Also, as I said below, _THIS WORKS ON ZFS_. That immediately means that a >>> CoW filesystem _does not_ need to behave like BTRFS is.

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017年08月02日 16:38, Brendan Hide wrote: The title seems alarmist to me - and I suspect it is going to be misconstrued. :-/ From the release notes at

Re: Power down tests...

Thanks guys. I've enabled that option now. Let's see how it goes. One general question regarding the stability of btrfs in kernel version 4.4. Is this okay for power off test cases? Or are there many important fixes in newer kernels? On Fri, Aug 4, 2017 at 5:24 PM, Dmitrii Tcvetkov

[PATCH] btrfs: Fix -EOVERFLOW handling in btrfs_ioctl_tree_search_v2

The buffer passed to btrfs_ioctl_tree_search* functions have to be at least sizeof(struct btrfs_ioctl_search_header). If this is not the case then the ioctl should return -EOVERFLOW and set the uarg->buf_size to the minimum required size. Currently btrfs_ioctl_tree_search_v2 would return an

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017-08-03 16:45, Brendan Hide wrote: On 08/03/2017 09:22 PM, Austin S. Hemmelgarn wrote: On 2017-08-03 14:29, Christoph Anton Mitterer wrote: On Thu, 2017-08-03 at 20:08 +0200, waxhead wrote: There are no higher-level management tools (e.g. RAID management/monitoring, etc.)... [snip]

Re: SQLite Re: csum errors on top of dm-crypt

Roman Mamedov posted on Fri, 04 Aug 2017 12:44:44 +0500 as excerpted: > On Fri, 4 Aug 2017 12:18:58 +0500 Roman Mamedov wrote: > >> What I find weird is why the expected csum is the same on all of these. >> Any idea what this might point to as the cause? >> >> What is

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

Austin S. Hemmelgarn posted on Thu, 03 Aug 2017 15:03:53 -0400 as excerpted: >> Same thing with the trim feature that is marked OK . It clearly says >> that is has performance implications. It is marked OK so one would >> expect it to not cause the filesystem to fail, but if the performance >>

Re: csum errors on top of dm-crypt

On Fri, 4 Aug 2017 12:44:44 +0500 Roman Mamedov wrote: > > What is 0x98f94189, is it not a csum of a block of zeroes by any chance? > > It does seem to be something of that sort Actually, I think I know what happened. I used "dd bs=1M conv=sparse" to copy source FS onto a

Re: Power down tests...

Oh ok. I read this in the man page and assumed that it's on by default: flushoncommit, noflushoncommit (default: on) This option forces any data dirtied by a write in a prior transaction to commit as part of the current commit. This makes the committed state a fully

SQLite Re: csum errors on top of dm-crypt

On Fri, 4 Aug 2017 12:18:58 +0500 Roman Mamedov wrote: > What I find weird is why the expected csum is the same on all of these. > Any idea what this might point to as the cause? > > What is 0x98f94189, is it not a csum of a block of zeroes by any chance? It does seem to be

Re: Power down tests...

On Fri, Aug 04, 2017 at 12:15:12PM +0530, Shyam Prasad N wrote: > Is flushoncommit not a default option on version > 4.4? Do I need specifically set this option? It's not the default. -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your

csum errors on top of dm-crypt

Hello, I've migrated my home dir to a luks dm-crypt device some time ago, and today during a scheduled backup a few files turned out to be unreadable, with csum errors from Btrfs in dmesg. What I find weird is why the expected csum is the same on all of these. Any idea what this might point to

Re: Power down tests...

On Fri, Aug 04, 2017 at 11:21:15AM +0530, Shyam Prasad N wrote: > We're running a couple of experiments on our servers with btrfs > (kernel version 4.4). > And we're running some abrupt power-off tests for a couple of scenarios: > > 1. We have a filesystem on top of two different btrfs