Re: [PATCH 01/10] btrfs: create a mount option for dax

On Wed, Dec 05, 2018 at 02:43:03PM +0200, Nikolay Borisov wrote: > One question below though . > > > +++ b/fs/btrfs/super.c > > @@ -739,6 +741,17 @@ int btrfs_parse_options(struct btrfs_fs_info *info, > > char *options, > > case Opt_user_subvol_rm_allowed: > >

Re: [PATCH 00/10] btrfs: Support for DAX devices

On Wed, Dec 05, 2018 at 06:28:25AM -0600, Goldwyn Rodrigues wrote: > This is a support for DAX in btrfs. Yay! > I understand there have been previous attempts at it. However, I wanted > to make sure copy-on-write (COW) works on dax as well. btrfs' usual use of CoW and DAX are thoroughly in

Re: [PATCH 7/9] btrfs-progs: Fix Wmaybe-uninitialized warning

On Tue, Dec 04, 2018 at 01:17:04PM +0100, David Sterba wrote: > On Fri, Nov 16, 2018 at 03:54:24PM +0800, Qu Wenruo wrote: > > The only location is the following code: > > > > int level = path->lowest_level + 1; > > BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL); > > while(level <

[PATCH RESEND 1/2] btrfs-progs: fix kernel version parsing on some versions past 3.0

The code fails if the third section is missing (like "4.18") or is followed by anything but "." or "-". This happens for example if we're not exactly at a tag and CONFIG_LOCALVERSION_AUTO=n (which results in "4.18.5+"). Signed-off-by: Adam Borowski --- f

[PATCH RESEND-v3 2/2] btrfs-progs: defrag: open files RO on new enough kernels

616d374efa23). Signed-off-by: Adam Borowski --- v2: more eloquent description; root can't defrag RO on old kernels (unlike dedupe) v3: more eloquentier description; s/defrag_ro/defrag_open_mode/ cmds-filesystem.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/cmds

Re: Filesystem mounts fine but hangs on access

On Sun, Nov 04, 2018 at 06:29:06PM +, Duncan wrote: > So do consider adding noatime to your mount options if you haven't done > so already. AFAIK, the only /semi-common/ app that actually uses atimes > these days is mutt (for read-message tracking), and then not for mbox, so > you should

Re: python-btrfs v10 preview... detailed usage reporting and a tutorial

On Mon, Oct 08, 2018 at 02:03:44AM +0200, Hans van Kranenburg wrote: > And yes, when promoting things like the new show_usage example to > programs that are easily available, users will probably start parsing > the output of them with sed and awk which is a total abomination and the > absolute

Re: python-btrfs v10 preview... detailed usage reporting and a tutorial

On Sun, Sep 23, 2018 at 11:54:12PM +0200, Hans van Kranenburg wrote: > Two examples have been added, which use the new code. I would appreciate > extra testing. Please try them and see if the reported numbers make sense: > > space_calculator.py > --- > Best to be initially

Re: Transactional btrfs

On Sat, Sep 08, 2018 at 08:45:47PM +, Martin Raiber wrote: > Am 08.09.2018 um 18:24 schrieb Adam Borowski: > > On Thu, Sep 06, 2018 at 06:08:33AM -0400, Austin S. Hemmelgarn wrote: > >> On 2018-09-06 03:23, Nathan Dehnel wrote: > >>> So I guess my question is, do

Re: Transactional btrfs

On Thu, Sep 06, 2018 at 06:08:33AM -0400, Austin S. Hemmelgarn wrote: > On 2018-09-06 03:23, Nathan Dehnel wrote: > > So I guess my question is, does btrfs support atomic writes across > > multiple files? Or is anyone interested in such a feature? > > > I'm fairly certain that it does not

Re: dduper - Offline btrfs deduplication tool

On Fri, Sep 07, 2018 at 09:27:28AM +0530, Lakshmipathi.G wrote: > > One question: > > Why not ioctl_fideduperange? > > i.e. you kill most of benefits from that ioctl - atomicity. > > > I plan to add fideduperange as an option too. User can > choose between fideduperange and ficlonerange call. >

[PATCH v3] btrfs-progs: defrag: open files RO on new enough kernels

616d374efa23). Signed-off-by: Adam Borowski --- v2: more eloquent description; root can't defrag RO on old kernels (unlike dedupe) v3: more eloquentier description; s/defrag_ro/defrag_open_mode/ cmds-filesystem.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/cmds

[PATCH v2] btrfs-progs: defrag: open files RO on new enough kernels

-by: Adam Borowski --- v2: more eloquent description; root can't defrag RO on old kernels (unlike dedupe) cmds-filesystem.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/cmds-filesystem.c b/cmds-filesystem.c index 06c8311b..17e992a3 100644 --- a/cmds-filesystem.c

Re: [PATCH 2/2] btrfs-progs: defrag: open files RO on new enough kernels or if root

On Mon, Sep 03, 2018 at 02:04:23PM +0300, Nikolay Borisov wrote: > On 3.09.2018 13:14, Adam Borowski wrote: > > - fd = open(fpath, O_RDWR); > > + fd = open(fpath, defrag_ro); > > Looking at the kernel code I think this is in fact incorrect, because

Re: [PATCH 2/2] btrfs-progs: defrag: open files RO on new enough kernels or if root

On Mon, Sep 03, 2018 at 02:01:21PM +0300, Nikolay Borisov wrote: > On 3.09.2018 13:14, Adam Borowski wrote: > > Fixes EXTXBSY races. > > You have to be more eloquent than that and explain at least one race > condition. If you try to defrag an executable that's currently runni

Re: IO errors when building RAID1.... ?

On Sun, Sep 02, 2018 at 09:15:25PM -0600, Chris Murphy wrote: > For > 10 years drive firmware handles bad sector remapping internally. > It remaps the sector logical address to a reserve physical sector. > > NTFS and ext[234] have a means of accepting a list of bad sectors, and > will avoid using

[PATCH 1/2] btrfs-progs: fix kernel version parsing on some versions past 3.0

The code fails if the third section is missing (like "4.18") or is followed by anything but "." or "-". This happens for example if we're not exactly at a tag and CONFIG_LOCALVERSION_AUTO=n (which results in "4.18.5+"). Signed-off-by: Adam Borowski --- f

[PATCH 2/2] btrfs-progs: defrag: open files RO on new enough kernels or if root

Fixes EXTXBSY races. Signed-off-by: Adam Borowski --- cmds-filesystem.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/cmds-filesystem.c b/cmds-filesystem.c index 06c8311b..4c9df69f 100644 --- a/cmds-filesystem.c +++ b/cmds-filesystem.c @@ -26,6 +26,7

Re: lazytime mount option—no support in Btrfs

On Mon, Aug 20, 2018 at 08:16:16AM -0400, Austin S. Hemmelgarn wrote: > Also, slightly OT, but atimes are not where the real benefit is here for > most people. No sane software other than mutt uses atimes (and mutt's use > of them is not sane, but that's a different argument) Right. There are

Re: [RESEND][PATCH v5 0/2] vfs: better dedupe permission check

uped gets ETXTBUSY. The answer (as above) is to allow them to > open the targets ro - root can already do this. There was a patch from > Adam Borowski to fix this back in 2016 > The 2nd patch fixes our return code for permission denied to be > EPERM. For some reason we're returning EINVAL -

Re: BTRFS and databases

On Wed, Aug 01, 2018 at 05:45:15AM +0200, MegaBrutal wrote: > But there is still one question that I can't get over: if you store a > database (e.g. MySQL), would you prefer having a BTRFS volume mounted > with nodatacow, or would you just simply use ext4? > > I know that with nodatacow, I take

Re: [PATCH resend 1/2] btrfs: allow defrag on a file opened ro that has rw permissions

On Mon, Jul 23, 2018 at 05:26:24PM +0200, David Sterba wrote: > On Wed, Jul 18, 2018 at 12:08:59AM +0200, Adam Borowski wrote: (Combined with as-folded) | | btrfs: allow defrag on a file opened read-only that has rw permissions | | > > Requiring a rw descriptor conflicts both ways

[PATCH resend 1/2] btrfs: allow defrag on a file opened ro that has rw permissions

to consider it a rw operation. Thus, let's check only whether the file could have been opened rw. Such access control is still needed as currently defrag can use extra disk space, and might trigger bugs. Signed-off-by: Adam Borowski --- fs/btrfs/ioctl.c | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH resend 2/2] btrfs: defrag: return EPERM not EINVAL when only permissions fail

strerror(). Signed-off-by: Adam Borowski --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 01c150b6ab62..e96e3c3caca1 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2943,7 +2943,7 @@ static int

[PATCH resend 0/2] btrfs: fix races between exec and defrag

t;, off); if (lseek(fd, off, SEEK_SET) != off) die("lseek for write: %m\n"); if (write(fd, , 1) != 1) die("write: %m\n"); } return 0; } >From d040af09adb03daadbba4336700f40425a860320 Mon Sep 17 00:00:00 2001 From: Adam Borows

Re: unsolvable technical issues?

On Wed, Jun 27, 2018 at 08:50:11PM +0200, waxhead wrote: > Chris Murphy wrote: > > On Thu, Jun 21, 2018 at 5:13 PM, waxhead wrote: > > > According to this: > > > > > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > > > Page 4 , section 1.2 > > > > > > It claims that BTRFS still

Re: [PATCH RFC] btrfs: Do extra device generation check at mount time

On Thu, Jun 28, 2018 at 03:04:43PM +0800, Qu Wenruo wrote: > There is a reporter considering btrfs raid1 has a major design flaw > which can't handle nodatasum files. > > Despite his incorrect expectation, btrfs indeed doesn't handle device > generation mismatch well. > > This means if one

[PATCH] defrag: open files RO

NOT FOR MERGING -- requires kernel versioning Fixes EXTXBSY races. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- cmds-filesystem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmds-filesystem.c b/cmds-filesystem.c index 30a50bf5..7eb6b7bb 100644 ---

[PATCH 2/2] btrfs: defrag: return EPERM not EINVAL when only permissions fail

strerror(). Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index b75db9d72106..ae6a110987a7 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2563,7 +

[PATCH 1/2] btrfs: allow defrag on a file opened ro that has rw permissions

to consider it a rw operation. Thus, let's check only whether the file could have been opened rw. Such access control is still needed as currently defrag can use extra disk space, and might trigger bugs. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/ioctl.c | 3 ++- 1 file chan

[PATCH 0/2] btrfs: fix races between exec and defrag

Hi! Here's a patch to fix ETXTBSY races between defrag and exec -- similar to what was just submitted for dedupe, even to the point of being followed by a second patch that replaces EINVAL with EPERM. As defrag is not something you're going to do on files you don't write, I skipped complex rules

Re: [PATCH v2 2/3] btrfs: balance: add args info during start and resume

On Wed, May 16, 2018 at 10:57:57AM +0300, Nikolay Borisov wrote: > On 16.05.2018 05:51, Anand Jain wrote: > > Balance args info is an important information to be reviewed for the > > system audit. So this patch adds it to the kernel log. > > > > Example: > > > > -> btrfs bal start

Re: [PATCH 1/2] vfs: allow dedupe of user owned read-only files

On Sun, May 13, 2018 at 06:16:53PM +, Mark Fasheh wrote: > On Sat, May 12, 2018 at 04:49:20AM +0200, Adam Borowski wrote: > > On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote: > > > The permission check in vfs_dedupe_file_range() is too coarse - We >

Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted

On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote: > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote: > > Right now we return EINVAL if a process does not have permission to dedupe a > > file. This was an oversight on my part. EPERM gives a true description of > > the

Re: [PATCH 1/2] vfs: allow dedupe of user owned read-only files

On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote: > The permission check in vfs_dedupe_file_range() is too coarse - We > only allow dedupe of the destination file if the user is root, or > they have the file open for write. > > This effectively limits a non-root user from deduping

Re: [PATCH 2/2] btrfs: add balance args info during start and resume

On Thu, Apr 26, 2018 at 04:01:29PM +0800, Anand Jain wrote: > Balance args info is an important information to be reviewed on the > system under audit. So this patch adds that. This kept annoying me. Thanks a lot! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that!

Re: [wiki] Please clarify how to check whether barriers are properly implemented in hardware

On Mon, Apr 02, 2018 at 10:07:01PM +, Hugo Mills wrote: > On Mon, Apr 02, 2018 at 06:03:00PM -0400, Fedja Beader wrote: > > Is there some testing utility for this? Is there a way to extract this/tell > > with a high enough certainty from datasheets/other material before purchase? > >

Re: Question, will ls -l eventually be able to show subvolumes?

On Fri, Mar 30, 2018 at 10:42:10AM +0100, Pete wrote: > I've just notice work going on to make rmdir be able to delete > subvolumes. Is there an intent to allow ls -l to display directories as > subvolumes? That's entirely up to coreutils guys. Meow! -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To unsubscribe

Re: Raid1 volume stuck as read-only: How to dump, recreate and restore its content?

On Sun, Mar 11, 2018 at 11:28:08PM +0700, Andreas Hild wrote: > Following a physical disk failure of a RAID1 array, I tried to mount > the remaining volume of a root partition with "-o degraded". For some > reason it ended up as read-only as described here: >

Re: zerofree btrfs support?

On Sat, Mar 10, 2018 at 07:37:22PM +0500, Roman Mamedov wrote: > Note you can use it on HDDs too, even without QEMU and the like: via using LVM > "thin" volumes. I use that on a number of machines, the benefit is that since > TRIMed areas are "stored nowhere", those partitions allow for incredibly

Re: zerofree btrfs support?

On Sat, Mar 10, 2018 at 03:55:25AM +0100, Christoph Anton Mitterer wrote: > Just wondered... was it ever planned (or is there some equivalent) to > get support for btrfs in zerofree? Do you want zerofree for thin storage optimization, or for security? For the former, you can use fstrim; this is

Re: Metadata / Data on Heterogeneous Media

On Thu, Feb 15, 2018 at 12:15:49PM -0500, Ellis H. Wilson III wrote: > In discussing the performance of various metadata operations over the past > few days I've had this idea in the back of my head, and wanted to see if > anybody had already thought about it before (likely, I would guess). > > It

Re: btrfs-cleaner / snapshot performance analysis

On Sun, Feb 11, 2018 at 12:31:42PM +0300, Andrei Borzenkov wrote: > 11.02.2018 04:02, Hans van Kranenburg пишет: > >> - /dev/sda6 / btrfs > >> rw,relatime,ssd,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot > >> 0 0 > > > > Note that changes on atime cause writes to metadata, which means

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 09:54:04AM +0100, Tomasz Pala wrote: > On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote: > > > systemd can't possibly need to know more information than a person > > does in the exact same situation in order to do the right thing. No > > human would wait 10

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 03:36:48PM +0100, Goffredo Baroncelli wrote: > I think that the real problem relies that the mounting a btrfs filesystem > cannot be a responsibility of systemd (or whichever rc-system). > Unfortunately in the past it was thought that it would be sufficient to > assemble a

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: > On Sat, Jan 27, 2018 at 13:26:13 +0300, Andrei Borzenkov wrote: > > >> I just tested to boot with a single drive (raid1 degraded), even with > >> degraded option in fstab and grub, unable to boot ! The boot process > >> stop on

Re: hang in btrfs_async_reclaim_metadata_space

On Sun, Jan 07, 2018 at 01:17:19PM +0200, Nikolay Borisov wrote: > On 6.01.2018 07:10, Adam Borowski wrote: > > Hi! > > I got a reproducible infinite hang, reliably triggered by the testsuite of > > "flatpak"; fails on at least 4.15-rc6, 4.9.75, and on another mac

hang in btrfs_async_reclaim_metadata_space

Hi! I got a reproducible infinite hang, reliably triggered by the testsuite of "flatpak"; fails on at least 4.15-rc6, 4.9.75, and on another machine with Debian's 4.14.2-1. [580632.355107] INFO: task kworker/u8:2:11105 blocked for more than 120 seconds. [580632.355120] Not tainted

Re: Unexpected raid1 behaviour

On Mon, Dec 18, 2017 at 03:28:14PM -0700, Chris Murphy wrote: > On Mon, Dec 18, 2017 at 1:49 AM, Anand Jain wrote: > > Agreed. IMO degraded-raid1-single-chunk is an accidental feature > > caused by [1], which we should revert back, since.. > >- balance (to raid1

[PATCH] fs/*/Kconfig: drop links to 404-compliant http://acl.bestbits.at

This link is replicated in most filesystems' config stanzas. Referring to an archived version of that site is pointless as it mostly deals with patches; user documentation is available elsewhere. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- Sending this as one piece; if you guys

Re: exclusive subvolume space missing

On Sun, Dec 03, 2017 at 01:45:45AM +, Duncan wrote: > Tomasz Pala posted on Sat, 02 Dec 2017 18:18:19 +0100 as excerpted: > >> I got ~500 small files (100-500 kB) updated partially in regular > >> intervals: > >> > >> # du -Lc **/*.rrd | tail -n1 > >> 105Mtotal > > FWIW, I've no idea

Re: splat on 4.15-rc1: invalid ram_bytes for uncompressed inline extent

On Tue, Nov 28, 2017 at 08:51:07AM +0800, Qu Wenruo wrote: > On 2017年11月27日 22:22, David Sterba wrote: > > On Mon, Nov 27, 2017 at 02:23:49PM +0100, Adam Borowski wrote: > >> On 4.15-rc1, I get the following failure: > >> > >> BTRFS critical (device sda1): corr

splat on 4.15-rc1: invalid ram_bytes for uncompressed inline extent

Hi! On 4.15-rc1, I get the following failure: BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688 slot=43 ino=35691 file_offset=0, invalid ram_bytes for uncompressed inline extent, have 134 expect 281474976710677 Repeatable every boot attempt. 4.14 and earlier boot fine;

Re: Unrecoverable scrub errors

On Fri, Nov 17, 2017 at 08:19:11PM -0700, Chris Murphy wrote: > On Fri, Nov 17, 2017 at 8:41 AM, Nazar Mokrynskyi > wrote: > > >> [551049.038718] BTRFS warning (device dm-2): checksum error at logical > >> 470069460992 on dev > >>

Re: A partially failing disk in raid0 needs replacement

On Tue, Nov 14, 2017 at 10:36:22AM +0200, Klaus Agnoletti wrote: > I used to have 3x2TB in a btrfs in raid0. A few weeks ago, one of the ^ > 2TB disks started giving me I/O errors in dmesg like this: > > [388659.188988] Add. Sense: Unrecovered read error -

Re: updatedb does not index /home when /home is Btrfs

On Sat, Nov 04, 2017 at 09:26:36AM +0300, Andrei Borzenkov wrote: > 04.11.2017 07:49, Adam Borowski пишет: > > On Fri, Nov 03, 2017 at 06:15:53PM -0600, Chris Murphy wrote: > >> Ancient bug, still seems to be a bug. > >> https://bugzilla.redhat.com/show_bug.cgi?id

Re: updatedb does not index /home when /home is Btrfs

On Fri, Nov 03, 2017 at 06:15:53PM -0600, Chris Murphy wrote: > Ancient bug, still seems to be a bug. > https://bugzilla.redhat.com/show_bug.cgi?id=906591 > > The issue is that updatedb by default will not index bind mounts, but > by default on Fedora and probably other distros, put /home on a >

Re: Problem with file system

On Fri, Nov 03, 2017 at 04:03:44PM -0600, Chris Murphy wrote: > On Tue, Oct 31, 2017 at 5:28 AM, Austin S. Hemmelgarn > wrote: > > > If you're running on an SSD (or thinly provisioned storage, or something > > else which supports discards) and have the 'discard' mount

Re: [PATCH] btrfs: avoid misleading talk about "compression level 0"

On Wed, Oct 25, 2017 at 03:23:11PM +0200, David Sterba wrote: > On Sat, Oct 21, 2017 at 06:49:01PM +0200, Adam Borowski wrote: > > Many compressors do assign a meaning to level 0: either null compression or > > the lowest possible level. This differs from our "unset thus defau

Re: SLES 11 SP4: can't mount btrfs

On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote: > - Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.dun...@cox.net: > > Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted: > > > >> Is it generally possible to restore a btrfs partition from a tape backup > >> ? >

[PATCH] btrfs: avoid misleading talk about "compression level 0"

Many compressors do assign a meaning to level 0: either null compression or the lowest possible level. This differs from our "unset thus default". Thus, let's not unnecessarily confuse users. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/super.c | 4 +++- 1

Re: Is it safe to use btrfs on top of different types of devices?

On Wed, Oct 18, 2017 at 07:30:55AM -0400, Austin S. Hemmelgarn wrote: > On 2017-10-17 16:21, Adam Borowski wrote: > > > > It's a single-device filesystem, thus disconnects are obviously fatal. > > > > But, > > > > they never caused even a sin

Re: Is it safe to use btrfs on top of different types of devices?

On Tue, Oct 17, 2017 at 03:19:09PM -0400, Austin S. Hemmelgarn wrote: > On 2017-10-17 13:06, Adam Borowski wrote: > > On Tue, Oct 17, 2017 at 08:40:20AM -0400, Austin S. Hemmelgarn wrote: > > > On 2017-10-17 07:42, Zoltan wrote: > > > > On Tue, Oct 17, 2017 at

Re: Is it safe to use btrfs on top of different types of devices?

On Tue, Oct 17, 2017 at 08:40:20AM -0400, Austin S. Hemmelgarn wrote: > On 2017-10-17 07:42, Zoltan wrote: > > On Tue, Oct 17, 2017 at 1:26 PM, Austin S. Hemmelgarn > > wrote: > > > > > I forget sometimes that people insist on storing large volumes of data on > > >

Re: Is it safe to use btrfs on top of different types of devices?

On Mon, Oct 16, 2017 at 01:27:40PM -0400, Austin S. Hemmelgarn wrote: > On 2017-10-16 12:57, Zoltan wrote: > > On Mon, Oct 16, 2017 at 1:53 PM, Austin S. Hemmelgarn wrote: > In an ideal situation, scrubbing should not be an 'only if needed' thing, > even for a regular array that isn't dealing with

Re: Give up on bcache?

On Tue, Sep 26, 2017 at 11:33:19PM +0500, Roman Mamedov wrote: > On Tue, 26 Sep 2017 16:50:00 + (UTC) > Ferry Toth wrote: > > > https://www.phoronix.com/scan.php?page=article=linux414-bcache- > > raid=2 > > > > I think it might be idle hopes to think bcache can be used as

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Wed, Sep 13, 2017 at 08:21:01AM -0400, Austin S. Hemmelgarn wrote: > On 2017-09-12 17:13, Adam Borowski wrote: > > On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote: > > > On 2017-09-12 16:00, Adam Borowski wrote: > > > > Noted. Both Marat's and

[RFC PATCH 1/3] btrfs: allow to set compression level for zlib

From: David Sterba Preliminary support for setting compression level for zlib, the following works: $ mount -o compess=zlib # default $ mount -o compess=zlib0# same $ mount -o compess=zlib9# level 9, slower sync, less data $

[RFC PATCH 2/3] btrfs: allow setting zlib compression level via :9

This is bikeshedding, but it seems people are drastically more likely to understand "zlib:9" as compression level rather than an algorithm version compared to "zlib9". Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/compression.c | 2 ++ fs/btrfs/sup

[RFC PATCH 3/3] btrfs: allow setting zstd level

Capped at 15 because of currently used encoding, which is also a reasonable limit because highest levels shine only on blocks much bigger than btrfs' 128KB. Memory is allocated for the biggest supported level rather than for what is actually used. Signed-off-by: Adam Borowski <ki

[RFC 0/3]: settable compression level for zstd

Hi! Here's a patch set that allows changing the compression level for zstd, currently at mount time only. I've played with it for a month, so despite being a quick hack, it's reasonably well tested. Tested on 4.13 + btrfs-for-4.14 only, though -- I've booted 11th-day-of-merge-window only an hour

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote: > On 2017-09-12 16:00, Adam Borowski wrote: > > Noted. Both Marat's and my use cases, though, involve VMs that are off most > > of the time, and at least for me, turned on only to test something. > > Touch

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Tue, Sep 12, 2017 at 03:11:52PM -0400, Austin S. Hemmelgarn wrote: > On 2017-09-12 14:43, Adam Borowski wrote: > > On Tue, Sep 12, 2017 at 01:36:48PM -0400, Austin S. Hemmelgarn wrote: > > > On 2017-09-12 13:21, Adam Borowski wrote: > > > > There's fallocate -d, bu

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Tue, Sep 12, 2017 at 01:36:48PM -0400, Austin S. Hemmelgarn wrote: > On 2017-09-12 13:21, Adam Borowski wrote: > > There's fallocate -d, but that for some reason touches mtime which makes > > rsync go again. This can be handled manually but is still not nice. > It tou

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Tue, Sep 12, 2017 at 02:26:39PM +0300, Marat Khalili wrote: > On 12/09/17 14:12, Adam Borowski wrote: > > Why would you need support in the hypervisor if cp --reflink=always is > > enough? > +1 :) > > But I've already found one problem: I use rsync snapshots for backu

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Tue, Sep 12, 2017 at 02:01:53PM +0300, Timofey Titovets wrote: > > On 12/09/17 13:32, Adam Borowski wrote: > >> Just use raw -- btrfs already has every feature that qcow2 has, and > >> does it better. This doesn't mean btrfs is the best choice for hosting > >

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Tue, Sep 12, 2017 at 10:01:07AM +, Duncan wrote: > BTW, I am most definitely /not/ a VM expert, and won't pretend to > understand the details or be able to explain further, but IIRC from what > I've read on-list, qcow2 isn't the best alternative for hosting VMs on > top of btrfs.

Re: \o/ compsize

On Mon, Sep 04, 2017 at 10:33:40PM +0200, A L wrote: > On 9/4/2017 5:11 PM, Adam Borowski wrote: > > Hi! > > Here's an utility to measure used compression type + ratio on a set of files > > or directories: https://github.com/kilobyte/compsize > > Great tool. Just tr

Re: \o/ compsize

On Mon, Sep 04, 2017 at 07:07:25PM +0300, Timofey Titovets wrote: > 2017-09-04 18:11 GMT+03:00 Adam Borowski <kilob...@angband.pl>: > > Here's an utility to measure used compression type + ratio on a set of files > > or directories: https://github.com/kilobyte/comps

\o/ compsize

Hi! Here's an utility to measure used compression type + ratio on a set of files or directories: https://github.com/kilobyte/compsize It should be of great help for users, and also if you: * muck with compression levels * add new compression types * add heurestics that could err on withholding

Re: How to disable/revoke 'compression'?

On Sun, Sep 03, 2017 at 08:30:59PM +0200, Hans van Kranenburg wrote: > On 09/03/2017 08:06 PM, Adam Borowski wrote: > > On Sun, Sep 03, 2017 at 07:32:01PM +0200, Cloud Admin wrote: > >> Beside of it, is it possible to find out what the real and compressed size > >

Re: How to disable/revoke 'compression'?

On Mon, Sep 04, 2017 at 07:55:27AM +0800, Qu Wenruo wrote: > On 2017年09月04日 02:06, Adam Borowski wrote: > > I've once written a tool which does this, but 1. it's extremely slow, 2. > > insane, 3. so insane a certain member of this list would kill me had I > > distributed the

Re: How to disable/revoke 'compression'?

On Sun, Sep 03, 2017 at 07:32:01PM +0200, Cloud Admin wrote: > Hi, > I used the mount option 'compression' on some mounted sub volumes. How > can I revoke the compression? Means to delete the option and get all > data uncompressed on this volume. > Is it enough to remount the sub volume without

Re: status of inline deduplication in btrfs

On Mon, Aug 28, 2017 at 12:49:10PM +0530, shally verma wrote: > Am bit confused over here, is your description based on offline-dedupe > here Or its with inline deduplication? It doesn't matter _how_ you get to excessive reflinking, the resulting slowdown is the same. By the way, you can try

Re: status of inline deduplication in btrfs

On Sat, Aug 26, 2017 at 01:36:35AM +, Duncan wrote: > The second has to do with btrfs scaling issues due to reflinking, which > of course is the operational mechanism for both snapshotting and dedup. > Snapshotting of course reflinks the entire subvolume, so it's reflinking > on a

Re: Moving btrfs fs disk between computers

On Fri, Aug 18, 2017 at 11:09:22PM -0300, Hérikz Nawarro wrote: > Hello everyone, > > Can i create a btrfs fs in a machine and move the disk to another > machine like a ext4 or ntfs? Yeah, no problem whatsoever, even for multi-device filesystems. Btrfs doesn't care about what devices it is on.

Re: [PATCH v5 3/5] btrfs: Add zstd support

On Wed, Aug 09, 2017 at 07:39:02PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. Re-tested on arm64, amd64 and i386, this time everything seems fine so far. As I'm too lazy to have a separate test setup for the zlib level patch, I'm using a dummy

Re: Power down tests...

On Sun, Aug 06, 2017 at 08:15:45PM -0600, Chris Murphy wrote: > On Thu, Aug 3, 2017 at 11:51 PM, 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

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: 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

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

Re: Raid0 rescue

On Thu, Jul 27, 2017 at 08:25:19PM +, Duncan wrote: > >Welcome to RAID-0... > > As Hugo implies, RAID-0 mode, not just for btrfs but in general, is well > known among admins for being "garbage data not worth trying to recover" > mode. Not only is there no redundancy, but with raid0

Re: Best Practice: Add new device to RAID1 pool

On Mon, Jul 24, 2017 at 02:55:00PM -0600, Chris Murphy wrote: > Egads. > > Maybe Cloud Admin ought to consider using a filter to just balance the > data chunks across the three devices, and just leave the metadata on > the original two disks? Balancing when adding a new disk isn't that important

Re: degraded raid scribbling upon wrong device

On Thu, Jul 13, 2017 at 08:40:12AM +0200, Adam Borowski wrote: > Here's a set of test cases, two of them in some cases seem to scribble upon > the wrong device: > > * deg-mid-missing > * deg-last-replaced (not on the innocent "re") > * but never deg-last-m

Re: btrfs device ready purpose

On Sat, Jul 22, 2017 at 06:15:58PM +, Hugo Mills wrote: > On Sat, Jul 22, 2017 at 12:06:17PM -0600, Chris Murphy wrote: > > I just did an additional test that's pretty icky behavior. > > > > 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready` > > exits with 0 as expected.

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On Fri, Jul 21, 2017 at 11:56:21AM -0400, Austin S. Hemmelgarn wrote: > On 2017-07-20 17:27, Nick Terrell wrote: > > 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,

Re: [PATCH RESEND] Btrfs: fix early ENOSPC due to delalloc

On Thu, Jul 20, 2017 at 03:10:35PM -0700, Omar Sandoval wrote: > If a lot of metadata is reserved for outstanding delayed allocations, we > rely on shrink_delalloc() to reclaim metadata space in order to fulfill > reservation tickets. However, shrink_delalloc() has a shortcut where if > it

Re: [PATCH v3] Btrfs: add skeleton code for compression heuristic

On Fri, Jul 21, 2017 at 11:37:49PM +0500, Roman Mamedov wrote: > On Fri, 21 Jul 2017 13:00:56 +0800 > Anand Jain wrote: > > On 07/18/2017 02:30 AM, David Sterba wrote: > > > This must stay 'return 1', if force-compress is on, so the change is > > > reverted. > > > >

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

On Fri, Jul 21, 2017 at 01:47:11PM +0200, Hans van Kranenburg wrote: > The changes in here do the following: > > 1. Throw out the current ssd_spread behaviour. > 2. Move the current ssd behaviour to the ssd_spread option. > 3. Make ssd mode data allocation identical to tetris mode, like nossd. >

degraded raid scribbling upon wrong device

Hi! Here's a set of test cases, two of them in some cases seem to scribble upon the wrong device: * deg-mid-missing * deg-last-replaced (not on the innocent "re") * but never deg-last-missing When all goes ok, there are no errors other than wrong generation on the re-added disk (expected).

  1   2   3   >