[PATCH] btrfs-progs: man mkfs.btrfs: document -O^

Signed-off-by: Adam Borowski kilob...@angband.pl --- Documentation/mkfs.btrfs.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/mkfs.btrfs.asciidoc b/Documentation/mkfs.btrfs.asciidoc index fd20ca5..a9aa3cb 100644 --- a/Documentation/mkfs.btrfs.asciidoc

[PATCH] btrfs-progs: doc: document btrfs-select-super(8)

Signed-off-by: Adam Borowski <kilob...@angband.pl> --- Documentation/Makefile.in | 1 + Documentation/btrfs-select-super.asciidoc | 29 + 2 files changed, 30 insertions(+) create mode 100644 Documentation/btrfs-select-super.asciidoc diff

Transaction aborted in btrfs_rename2

Hi! I just got this thrice, in 4.7-rc1 and 4.7-rc2: [ 1836.672368] [ cut here ] [ 1836.672382] WARNING: CPU: 1 PID: 16348 at fs/btrfs/inode.c:9820 btrfs_rename2+0xcd2/0x2a50 [ 1836.672385] BTRFS: Transaction aborted (error -2) [ 1836.672387] Modules linked in: nvidia(PO)

Re: fsck: to repair or not to repair

On Fri, Jun 10, 2016 at 08:54:36AM -0700, Nikolaus Rath wrote: > On Jun 10 2016, "Austin S. Hemmelgarn" wrote: > > JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid > > it making reflinks. > > I would have expected so, but at least in coreutils 8.23 the

Re: fsck: to repair or not to repair

On Fri, Jun 10, 2016 at 01:12:42PM -0400, Austin S. Hemmelgarn wrote: > On 2016-06-10 12:50, Adam Borowski wrote: > >And, as of coreutils 8.25, the default is no reflink, with "never" not being > >recognized even as a way to avoid an alias. As far as I remember, this

Re: [PATCH] btrfs,vfs: allow FILE_EXTENT_SAME on a file opened ro

On Fri, May 27, 2016 at 09:59:22PM -0400, Zygo Blaxell wrote: > On Thu, May 26, 2016 at 05:04:01PM -0700, Mark Fasheh wrote: > > On Fri, May 20, 2016 at 05:45:12AM +0200, Adam Borowski wrote: > > > (Only btrfs currently implements dedupe_file_range.) > > > > &g

Re: [PATCH] btrfs,vfs: allow FILE_EXTENT_SAME on a file opened ro

On Sat, May 28, 2016 at 08:56:39PM -0400, Zygo Blaxell wrote: > On Sun, May 29, 2016 at 02:21:03AM +0200, Adam Borowski wrote: > > In any case, this patch doesn't introduce any cases not already triggerable > > by root. > > It allows non-root to trigger cases that

Re: [PATCH] btrfs,vfs: allow FILE_EXTENT_SAME on a file opened ro

On Fri, May 20, 2016 at 05:45:12AM +0200, Adam Borowski wrote: > (Only btrfs currently implements dedupe_file_range.) > > Instead of checking the mode of the file descriptor, let's check whether > it could have been opened rw. This allows fixing failures when deduping > a live

Re: [PATCH] btrfs,vfs: allow FILE_EXTENT_SAME on a file opened ro

On Thu, May 26, 2016 at 05:04:01PM -0700, Mark Fasheh wrote: > On Fri, May 20, 2016 at 05:45:12AM +0200, Adam Borowski wrote: > > (Only btrfs currently implements dedupe_file_range.) > > > > Instead of checking the mode of the file descriptor, let's check whether > > i

Re: btrfs_destroy_inode WARN_ON.

On Mon, Mar 28, 2016 at 04:14:46PM +0200, Markus Trippelsdorf wrote: > On 2016.03.28 at 10:05 -0400, Josef Bacik wrote: > > >Mar 24 10:37:27 x4 kernel: WARNING: CPU: 3 PID: 11838 at > > >fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x22b/0x2a0 > > > > I saw this running some xfstests on our

Re: [PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

On Thu, May 19, 2016 at 04:10:20PM -0400, Chris Mason wrote: > On Tue, May 17, 2016 at 10:47:27PM +0200, Adam Borowski wrote: > > On Tue, May 17, 2016 at 12:23:44PM -0400, Chris Mason wrote: > > > On Tue, May 17, 2016 at 05:14:51PM +0200, Adam Borowski wrote: > > > >

[PATCH] btrfs,vfs: allow FILE_EXTENT_SAME on a file opened ro

this ioctl on a ro file was already allowed for root/cap. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/read_write.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/read_write.c b/fs/read_write.c index cf377cf..6c414d8 100644 --- a/fs/read_write.c +++ b/fs/read_w

Re: WARNING at fs/btrfs/inode.c:9261 btrfs_destroy_inode()

Chris Mason wrote: > On Tue, May 10, 2016 at 06:19:20PM -0500, Eric Biggers wrote: > > The following warning has been triggering for me since about v4.6-rc3: > > > > WARN_ON(BTRFS_I(inode)->csum_bytes); > > > > On one machine the warning has occurred 657 times since v4.6-rc5. On > >

[PATCH for 4.6] btrfs: disable a spurious WARN_ON in btrfs_destroy_inode.

the no longer helpful register+stack dump with a printk that mentions the device affected. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/inode.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 2aaba58..ed78104

Re: [PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

On Tue, May 17, 2016 at 12:23:44PM -0400, Chris Mason wrote: > On Tue, May 17, 2016 at 05:14:51PM +0200, Adam Borowski wrote: > > On Mon, May 16, 2016 at 05:06:55PM -0400, Chris Mason wrote: > > > And now for the patch: > > [...] > > > > I then tried your

Re: [PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

On Tue, May 17, 2016 at 05:00:49PM -0400, Chris Mason wrote: > On Tue, May 17, 2016 at 10:47:27PM +0200, Adam Borowski wrote: > > > Hmmm, some of your traces mentioned compression, do you have compression > > > enabled? > > > > Yeah, I mount with noatime,compress

[PATCH] btrfs: fix int32 overflow in shrink_delalloc().

the space reservation won't be enough. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/extent-tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 84e060e..391f576 100644 --- a/fs/btrfs/extent-tree.c

Re: apt taints kernel - btrfs destroys inode

Duncan wrote: > > btrfs_destroy_inode > That's a known apparent false-positive warning on current 4.6-rc kernel > btrfs. The destroy-inode bit is related to a file deletion happening in > the normal order of things, where this warning code is run, and > apparently triggers even under normal

Re: A lot warnings in dmesg while running thunderbird

On Thu, Jul 21, 2016 at 11:25:02PM +0200, Gabriel C wrote: > On 21.07.2016 14:56, Chris Mason wrote: > > On 07/20/2016 01:50 PM, Gabriel C wrote: > >> After 24h of running the program and thundirbird all is still fine here. > >> > >> I let it run one more day.. But looks very good. > >> > > > >

Re: Extents for a particular subvolume

On Wed, Aug 03, 2016 at 08:56:01PM +0100, Graham Cobb wrote: > Are there any btrfs commands (or APIs) to allow a script to create a > list of all the extents referred to within a particular (mounted) > subvolume? And is it a reasonably efficient process (i.e. doesn't > involve backrefs and,

Re: checksum error in metadata node - best way to move root fs to new drive?

On Thu, Aug 11, 2016 at 04:23:45PM -0400, Dave T wrote: > 1. Can one discontinue using the compress mount option if it has been > used previously? The mount option applies only to newly written blocks, and even then only to files that don't say otherwise (via chattr +c or +C, btrfs property,

[PATCH] vfs: allow FILE_EXTENT_SAME (dedupe_file_range) on a file opened ro

for root/cap. Tested on btrfs and not-yet-merged xfs, as only them implement this ioctl. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/read_write.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/read_write.c b/fs/read_write.c index 933b53a..df59dc6

Re: [PATCH] vfs: allow FILE_EXTENT_SAME (dedupe_file_range) on a file opened ro

On Mon, Jul 18, 2016 at 12:13:38AM +0200, Adam Borowski wrote: > Instead of checking the mode of the file descriptor, let's check whether it > could have been opened rw. This allows fixing intermittent exec failures > when deduping a live system: anyone trying to exec a file curren

Re: How can I get blockdev offsets of btrfs chunks for a file?

On Fri, Jul 15, 2016 at 04:21:31PM -0700, Eric Wheeler wrote: > We do btrfs subvolume snapshots over time for backups. I would like to > traverse the files in the subvolumes and find the total unique chunk count > to calculate total space for a set of subvolumes. > > This sounds kind of like

Re: A lot warnings in dmesg while running thunderbird

On Fri, Jul 08, 2016 at 12:02:35PM -0400, Chris Mason wrote: > On 07/08/2016 11:02 AM, Gabriel C wrote: > > [btrfs_destroy_inode again] > Can you please run the attached test program: > > gcc -o short-write short-write.c -lpthread > ./short-write some-new-file-on-btrfs > > I want to see if

Re: A lot warnings in dmesg while running thunderbird

On Fri, Jul 08, 2016 at 08:21:16PM +0200, Adam Borowski wrote: > On Fri, Jul 08, 2016 at 12:02:35PM -0400, Chris Mason wrote: > > On 07/08/2016 11:02 AM, Gabriel C wrote: > > > [btrfs_destroy_inode again] > > > Can you please run the attached test program: > &

Re: Transaction aborted in btrfs_rename2

On Fri, Jul 29, 2016 at 11:43:29AM -0400, Jeff Mahoney wrote: > On 6/6/16 10:13 AM, Jeff Mahoney wrote: > > On 6/6/16 7:47 AM, Adam Borowski wrote: > >> Hi! > >> I just got this thrice, in 4.7-rc1 and 4.7-rc2: > >> > >> [ 1836.672368] --

Re: btrfs defrag questions

On Sun, Jul 03, 2016 at 04:15:02PM +0200, Henk Slager wrote: > >> Provided that Dropbox is running in the system, does it mean that it > >> cannot be defagmented? > > > > That is probably true. Files that are mapped into memory (like running > > executables) cannot be changed on disk. You could

Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

On Wed, Feb 01, 2017 at 05:23:16AM +, Duncan wrote: > Hans Deragon posted on Tue, 31 Jan 2017 21:51:22 -0500 as excerpted: > > But the current scenario makes it difficult for me to put redundancy > > back into service! How much time did I waited until I find the mailing > > list, subscribe to

Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

On Thu, Feb 02, 2017 at 07:49:50AM -0500, Austin S. Hemmelgarn wrote: > This is a severe bug that makes a not all that uncommon (albeit bad) use > case fail completely. The fix had no dependencies itself and I don't see what's bad in mounting a RAID degraded. Yeah, it provides no redundancy but

Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

./configure --host=zx-spectrum --build=pdp11 >From 1367d3da6b0189797f6090b11d8716a1cc136593 Mon Sep 17 00:00:00 2001 From: Adam Borowski <kilob...@angband.pl> Date: Mon, 23 Jan 2017 19:03:20 +0100 Subject: [PATCH] [NOT-FOR-MERGING] btrfs: make "too many missing devices" check no

Re: Raid1 won't mount degraded

figure --host=zx-spectrum --build=pdp11 >From 1367d3da6b0189797f6090b11d8716a1cc136593 Mon Sep 17 00:00:00 2001 From: Adam Borowski <kilob...@angband.pl> Date: Mon, 23 Jan 2017 19:03:20 +0100 Subject: [PATCH] [NOT-FOR-MERGING] btrfs: make "too many missing devices" check

Re: Raid1 won't mount degraded

On Sun, Jan 29, 2017 at 08:26:54PM -0500, Subscription Account wrote: > On Sun, Jan 29, 2017 at 3:16 PM, Adam Borowski <kilob...@angband.pl> wrote: > > On Sun, Jan 29, 2017 at 08:12:56AM -0500, Subscription Account wrote: > >> [ 2506.816795] BTRFS: missing device

Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

On Fri, Jan 27, 2017 at 03:03:18PM -0500, Austin S. Hemmelgarn wrote: > On 2017-01-27 11:47, Hans Deragon wrote: > > However, as a user, I am seeking for an easy, no maintenance raid > > solution. I wish that if a drive fails, the btrfs filesystem still > > mounts rw and leaves the OS running,

Re: Btrfs Heatmap - v5 ... snake, linear ... the virtual address space

On Sun, Feb 19, 2017 at 01:01:29AM +0100, Hans van Kranenburg wrote: > I just tagged v5 of the Btrfs Heatmap utility, which visualizes the > usage of your btrfs filesystem > Since I got tired of cloning and updating the thing all over the place, > I added debian packaging. I'm planning to get all

Re: [PULL] Fix ioctls on 32bit/64bit userspace/kernel, for 4.10

On Wed, Feb 08, 2017 at 05:51:28PM +0100, David Sterba wrote: > could you please merge this single-patch pull request, for 4.10 still? There > are quite a few patches on top of v4.10-rc7 so this IMHO does not look like > look too bad even late in the release cycle. Though it's a fix for an

Re: BTRFS and cyrus mail server

On Wed, Feb 08, 2017 at 02:21:13PM -0500, Austin S. Hemmelgarn wrote: > > - maybe deduplication (cyrus does it by hardlinking of same content > > messages > > now) later > Deduplication beyond what Cyrus does is probably not worth it. In most > cases about 10% of an e-mail in text form is going

Re: understanding disk space usage

On Wed, Feb 08, 2017 at 11:48:04AM +0800, Qu Wenruo wrote: > Just don't believe the vanilla df output for btrfs. > > For btrfs, unlike other fs like ext4/xfs, which allocates chunk dynamically > and has different metadata/data profile, we can only get a clear view of the > fs from both chunk

Re: 4.9/4.10 Experiences

On Thu, Feb 16, 2017 at 01:37:53PM +0200, Imran Geriskovan wrote: > What are your experiences for btrfs regarding 4.10 and 4.11 kernels? > I'm still on 4.8.x. I'd be happy to hear from anyone using 4.1x for > a very typical single disk setup. Are they reasonably stable/good > enough for this case?

Re: BTRFS hybrid system setup issues

On Sun, Feb 26, 2017 at 10:47:40AM +0530, Bhasker C V wrote: > I compiled kernel 4.10 and I can confirm it is working fnie now. 4.10 > has the compat-ioctl patches for btrfs progs to work with x86_64 > kernel in i386 userland. So does 4.9.10 if you prefer running long-lived releases. --

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On Wed, Mar 01, 2017 at 05:30:37PM -0700, Chris Murphy wrote: > [1717713.408675] BTRFS warning (device dm-8): missing devices (1) > exceeds the limit (0), writeable mount is not allowed > [1717713.446453] BTRFS error (device dm-8): open_ctree failed > > [chris@f25s ~]$ uname -r >

Re: compress=lzo safe to use? (was: Re: Trying to rescue my data :()

On Sun, Sep 11, 2016 at 09:48:35PM +0200, Martin Steigerwald wrote: > Hmm… I found this from being referred to by reading Debian wiki page on > BTRFS¹. > > I use compress=lzo on BTRFS RAID 1 since April 2014 and I never found an > issue. Steven, your filesystem wasn´t RAID 1 but RAID 5 or 6? >

Re: Size of scrubbed Data

On Sat, Sep 17, 2016 at 01:02:18PM +0200, Stefan Malte Schumacher wrote: > Concerning Testing: I only use it on desktops and home servers, which > do not offer any services to the net. I am very fond of Debian and > always use stable or even old-stable on work servers, but was finally > to annoyed

Re: does btrfs-receive use/compare the checksums from the btrfs-send side?

On Sun, Aug 28, 2016 at 07:50:42PM +0200, Christoph Anton Mitterer wrote: > On Sun, 2016-08-28 at 11:35 -0600, Chris Murphy wrote: > > I don't see evidence of them in the btrfs send file, so I don't think > > csums are in the stream. > > hmm... isn't that kinda unfortunate not to make use of the

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

On Thu, Sep 29, 2016 at 09:27:01AM +0200, Stefan Priebe - Profihost AG wrote: > Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: > >>> I found that compress sometime report ENOSPC error even in 4.8-rc8, > >>> currently > >> I cannot confirm that as i do not have anough space to test this without >

Re: [PATCH] btrfs: make block group flags in balance printks human-readable

On Mon, Nov 07, 2016 at 05:58:41PM +0100, David Sterba wrote: > On Fri, Nov 04, 2016 at 08:26:54AM +0100, Adam Borowski wrote: > > They're not even documented anywhere, letting users with no recourse but > > to RTFS. It's no big burden to output the bitfield as words. > &g

[PATCH v2] btrfs: make block group flags in balance printks human-readable

They're not even documented anywhere, letting users with no recourse but to RTFS. It's no big burden to output the bitfield as words. Also, display unknown flags as hex. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/relocation.

Re: Announcing btrfs-dedupe

On Mon, Nov 07, 2016 at 09:48:41AM -0800, Mark Fasheh wrote: > also on XFS with the dedupe ioctl (I believe this should be out with > Linux-4.9). It's already there in 4.9-rc1, although you need a special version of xfsprogs (possibly already released, I didn't check). It's an experimental

Re: RAID system with adaption to changed number of disks

On Wed, Oct 12, 2016 at 01:19:37PM -0400, Zygo Blaxell wrote: > On Wed, Oct 12, 2016 at 01:48:58PM +0800, Qu Wenruo wrote: > > In fact, the _concept_ to solve such RMW behavior is quite simple: > > > > Make sector size equal to stripe length. (Or vice versa if you like) > > > > Although the

[PATCH v4] btrfs: make block group flags in balance printks human-readable

They're not even documented anywhere, letting users with no recourse but to RTFS. It's no big burden to output the bitfield as words. Also, display unknown flags as hex. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/relocation.

[PATCH] btrfs-progs: man mkfs: warn about RAID5/6 being experimental

Signed-off-by: Adam Borowski <kilob...@angband.pl> --- Documentation/mkfs.btrfs.asciidoc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/mkfs.btrfs.asciidoc b/Documentation/mkfs.btrfs.asciidoc index 9b1d45a..c92d730 100644 --- a/Documentation/mkfs.btrfs.asciidoc

[PATCH] btrfs-progs: mkfs, balance convert: warn about RAID5/6 in fiery letters

leaving experimental features without a warning is inappropriate. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- cmds-balance.c | 2 ++ mkfs.c | 2 ++ utils.c| 46 ++ utils.h| 2 ++ 4 files changed, 52 insertions(+)

Re: [PATCH] btrfs: raid56: Use correct stolen pages to calculate P/Q

On Tue, Nov 29, 2016 at 02:52:47AM +0100, Christoph Anton Mitterer wrote: > On Mon, 2016-11-28 at 16:48 -0500, Zygo Blaxell wrote: > > If a drive's embedded controller RAM fails, you get corruption on the > > majority of reads from a single disk, and most writes will be corrupted > > (even if they

[PATCH v3-onstack] btrfs: make block group flags in balance printks human-readable

They're not even documented anywhere, letting users with no recourse but to RTFS. It's no big burden to output the bitfield as words. Also, display unknown flags as hex. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/relocation.

Re: Resizing BTRFS - raw partition

On Wed, Nov 02, 2016 at 09:29:26AM +, Hugo Mills wrote: > On Wed, Nov 02, 2016 at 10:18:03AM +0100, Christian Völker wrote: > > thanks for the quick reply. Regarding version- I prefer to use stable > > Linux versionsand I am not going to upgrade just btrfs outside of > > the verndors

[PATCH] btrfs: make block group flags in balance printks human-readable

They're not even documented anywhere, letting users with no recourse but to RTFS. It's no big burden to output the bitfield as words. Also, display unknown flags as hex. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/relocation.c | 34 --

Re: RAID system with adaption to changed number of disks

On Wed, Oct 12, 2016 at 05:10:18PM -0400, Zygo Blaxell wrote: > On Wed, Oct 12, 2016 at 09:55:28PM +0200, Adam Borowski wrote: > > On Wed, Oct 12, 2016 at 01:19:37PM -0400, Zygo Blaxell wrote: > > > I had been thinking that we could inject "plug" extents to fill up &

Re: [PATCH] btrfs-progs: mkfs, balance convert: warn about RAID5/6 in fiery letters

On Wed, Nov 30, 2016 at 04:12:46PM +0100, David Sterba wrote: > On Mon, Nov 28, 2016 at 07:51:53PM +0100, Adam Borowski wrote: > > People who don't frequent IRC nor the mailing list tend to believe RAID 5/6 > > are stable; this leads to data loss. Thus, let's do warn them. > &g

Re: out-of-band dedup status?

On Thu, Dec 08, 2016 at 07:54:39PM -0700, Chris Murphy wrote: > On Thu, Dec 8, 2016 at 7:26 PM, Darrick J. Wong > wrote: > > Ew, it's deduping these two 1.4GB files 128K at a time, which results in > > 12000 ioctl calls. Each of those 12000 calls has to lock the two > >

Re: out-of-band dedup status?

On Thu, Dec 08, 2016 at 03:15:38PM -0500, Jeff Mahoney wrote: > On 12/8/16 1:36 PM, Christoph Anton Mitterer wrote: > > I just wondered whether out-of-band/"offline" dedup is safe for general > > use... https://btrfs.wiki.kernel.org/index.php/Status kinda implies so > > (it tells about unspecified

corrupt leaf on just-created filesystem

Got a 100% reproducible splat on 4.9. So I plopped in a fresh 4TB disk: dd if=/dev/zero of=meow bs=1 seek=4000785104895 count=1 mkfs -t btrfs meow mount -onoatime meow /mnt/vol1 cd /mnt/vol1 btrfs subv create foo [ 104.867344] BTRFS: device label diediedie devid 1 transid 5 /dev/sdc1 [

Re: corrupt leaf on just-created filesystem

On Fri, Dec 16, 2016 at 10:53:48AM -0800, Liu Bo wrote: > On Fri, Dec 16, 2016 at 10:44:11AM -0500, Jeff Mahoney wrote: > > On 12/16/16 4:18 AM, Adam Borowski wrote: > > > Got a 100% reproducible splat on 4.9. > > > > > > So I plopped in a fresh 4TB disk: >

Re: system hangs due to qgroups

On Sat, Dec 03, 2016 at 10:46:40PM +0100, Marc Joliet wrote: > As it's a rescue shell, I have only the one shell AFAIK, and it's occupied > by mount. So I can't tell if there are dmesg entries, however, when this > happens during a normal running system, I never saw any dmesg entries. You can

Re: btrfs_log2phys: cannot lookup extent mapping

On Thu, Dec 22, 2016 at 01:28:37PM -0500, Austin S. Hemmelgarn wrote: > On 2016-12-22 10:14, Adam Borowski wrote: > > On the other, other filesystems: > > * suffer from silent data loss every time the disk doesn't notice an error! > > Allowing silent data loss fails the m

Re: btrfs_log2phys: cannot lookup extent mapping

On Thu, Dec 22, 2016 at 10:11:35AM +, Duncan wrote: > Given the maturing-but-not-yet-fully-stable-and-mature state of btrfs > today, being no further from a usable current backup than the data you're > willing to lose, at least worst-case, remains an even stronger > recommendation than it

Re: backing up a file server with many subvolumes

On Sun, Mar 26, 2017 at 02:14:36PM +0500, Roman Mamedov wrote: > You could have done time-based snapshots on the top level (for /backup/), say, > every 6 hours, and keep those for e.g. a month. Then don't bother with any > other kind of subvolumes/snapshots on the backup machine, and do backups

Re: [PATCH 1/2] btrfs: warn about RAID5/6 being experimental at mount time

On Wed, Mar 29, 2017 at 09:27:32PM +0200, Christoph Anton Mitterer wrote: > On Wed, 2017-03-29 at 06:39 +0200, Adam Borowski wrote: > > Too many people come complaining about losing their data -- and indeed, > > there's no warning outside a wiki and the mailing list tribal knowledg

[PATCH 1/2] btrfs: warn about RAID5/6 being experimental at mount time

Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/disk-io.c | 8 1 file changed, 8 insertions(+) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index affd7aada057..a4c3e6628ec1 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3083,6 +3083,14 @@ int o

[PATCH 2/2] btrfs: clear the RAID5/6 incompat flag once no longer needed

There's no known taint on a filesystem that was RAID5/6 once but has been since converted to something non-experimental. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- fs/btrfs/disk-io.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c

[PATCH v2] btrfs: drop the nossd flag when remounting with -o ssd

And when turning on nossd, drop ssd_spread. Reported-by: Hans van Kranenburg <hans.van.kranenb...@mendix.com> Signed-off-by: Adam Borowski <kilob...@angband.pl> --- On Fri, Mar 31, 2017 at 07:10:16PM +0200, David Sterba wrote: > On Fri, Mar 31, 2017 at 06:00:08PM +0200, Hans van K

Re: btrfs filesystem keeps allocating new chunks for no apparent reason

On Mon, Apr 10, 2017 at 03:43:57PM -0400, Austin S. Hemmelgarn wrote: > On 2017-04-10 14:18, Kai Krakow wrote: > * strictatime, lazytime: Both atime and mtime updates happen, but they > actual update may not hit the disk for up to 24 hours (this will let mutt > work correctly as long as your

Re: btrfs won't mount any more

On Tue, Apr 11, 2017 at 09:15:31AM +0200, Marc Haber wrote: > I have wrecked another btrfs file system, probably for good this time. > > It's a 80 GB filesystem from 2015, in my secondary notebook, on an > encrypted SSD. The btrfs holds the root filesystem and the rest of the > system as well. >

Re: Btrfs disk layout question

On Tue, Apr 11, 2017 at 12:15:32PM -0700, Amin Hassani wrote: > I am working on a project with Btrfs and I was wondering if there is > any way to see the disk layout of the btrfs image. Let's assume I have > a read-only btrfs image with compression on and only using one disk > (no raid or

Re: [PATCH v2] btrfs: drop the nossd flag when remounting with -o ssd

On Fri, Mar 31, 2017 at 10:24:57PM +0200, Hans van Kranenburg wrote: > >>> How did you test this? > >>> > >>> This was also my first thought, but here's a weird thing: > >>> > >>> -# mount -o nossd /dev/sdx /mnt/btrfs/ > >>> > >>> BTRFS info (device sdx): not using ssd allocation scheme > >>> >

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sun, Apr 09, 2017 at 05:58:54AM +0200, Adam Borowski wrote: > On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > > Unbreaks ARM and possibly other 32-bit architectures. > > Turns out those "other 32-bit architectures" happen to include i386. >

parity scrub on 32-bit

Hi! While messing with the division failure on current -next, I've noticed that parity scrub splats immediately on all 32-bit archs I tried. But, it's not a regression: it bisects to 5a6ac9eacb49143cbad3bbfda72263101cb1f3df (merged in 3.19) which happens to be when parity scrub was added. Ie, it

[PATCH] btrfs: scrub: use do_div() for 64-by-32 division

Unbreaks ARM and possibly other 32-bit architectures. Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len Reported-by: Icenowy Zheng <icen...@aosc.io> Signed-off-by: Adam Borowski <kilob...@angband.pl> --- You'd probably want to squash this with Liu's commit, to be ni

Re: Linux next-20170407 failed to build on ARM due to usage of mod in btrfs code

On Sat, Apr 08, 2017 at 02:45:34PM -0300, Fabio Estevam wrote: > On Sat, Apr 8, 2017 at 1:02 PM, Icenowy Zheng wrote: > > Hello everyone, > > Today I tried to build a kernel with btrfs enabled on ARM, then when linking > > I met such an error: > > > > ``` > > fs/built-in.o: In

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > Unbreaks ARM and possibly other 32-bit architectures. Turns out those "other 32-bit architectures" happen to include i386. A modular build: ERROR: "__udivdi3" [fs/btrfs/btrfs.ko] undefined! With the

Re: btrfs filesystem keeps allocating new chunks for no apparent reason

On Tue, Apr 11, 2017 at 06:01:19AM +0200, Kai Krakow wrote: > Yes, I know all this. But I don't see why you still want noatime or > relatime if you use lazytime, except for super-optimizing. Lazytime > gives you POSIX conformity for a problem that the other options only > tried to solve. (Besides

Re: [PATCH] btrfs: allow processes with cap_sys_resource to exceed quota

On Fri, Apr 21, 2017 at 10:09:46AM +, Sargun Dhillon wrote: > This patch allows processes with CAP_SYS_RESOURCE to exceed the qgroup > limit. It's useful for administrative programs, such as log rotation, > that may need to temporarily use more disk space in order to free up > a greater amount

Re: remount and conflicting ssd options?

On Sat, Apr 15, 2017 at 12:17:25PM -0600, Chris Murphy wrote: > I don't understand this: > > /dev/mmcblk0p3 on / type btrfs > (rw,noatime,seclabel,compress=zlib,nossd,ssd_spread,space_cache,commit=150,subvolid=260,subvol=/root) > > The fstab uses ssd_spread. It looks like during startup the

Re: remount and conflicting ssd options?

On Sat, Apr 15, 2017 at 12:41:14PM -0600, Chris Murphy wrote: > On Sat, Apr 15, 2017 at 12:31 PM, Adam Borowski <kilob...@angband.pl> wrote: > > On Sat, Apr 15, 2017 at 12:17:25PM -0600, Chris Murphy wrote: > >> Then later I tried > >> > >> mount -o remou

[PATCH ping] btrfs: warn about RAID5/6 being experimental at mount time

Signed-off-by: Adam Borowski <kilob...@angband.pl> --- Resent alone, the other patch in the original series (dropping the incompat flag when no longer needed) is pointless on its own. I intend to ask for inclusion of this one (or an equivalent) in 4.9, either in Debian or via GregKH -- whil

Re: [PATCH v2] btrfs: fix a bogus warning when converting only data or metadata

On Thu, Mar 09, 2017 at 02:43:27PM +0100, David Sterba wrote: > The patch does not apply to current master, there's > > 3861 if (bctl->sys.flags & BTRFS_BALANCE_ARGS_CONVERT) { > 3862 fs_info->num_tolerated_disk_barrier_failures = min( > 3863

Re: [PATCH v2 0/6] Chunk level degradable check

On Tue, Mar 07, 2017 at 09:35:56AM +0800, Qu Wenruo wrote: > At 03/07/2017 08:36 AM, Adam Borowski wrote: > > Not so for -draid5 -mraid1, unfortunately: > > Unfortunately, for raid5 there are still unfixed bugs. > In fact, some raid5/6 bugs are already fixed, but st

Re: [PATCH v2 0/6] Chunk level degradable check

On Mon, Mar 06, 2017 at 04:58:49PM +0800, Qu Wenruo wrote: > Btrfs currently uses num_tolerated_disk_barrier_failures to do global > check for tolerated missing device. > > Although the one-size-fit-all solution is quite safe, it's too strict if > data and metadata has different duplication

[PATCH] btrfs: fix a bogus warning when converting only data or metadata

ffect, non-convert balances will now nag about data>metadata. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- To reproduce: dd if=/dev/zero bs=1048576 count=1 seek=4095 of=ra dd if=/dev/zero bs=1048576 count=1 seek=4095 of=rb mkfs.btrfs ra rb # defaults to -draid0 -mraid1 loset

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On Fri, Mar 03, 2017 at 06:56:22AM +0100, Kai Krakow wrote: > > > I don't understand what problem this proscription is trying to > > > avoid. If it's OK to mount rw,degraded once, then it's OK to allow > > > it twice. If it's not OK twice, it's not OK once. > > > > Well, yeah. The current

[PATCH v2] btrfs: fix a bogus warning when converting only data or metadata

ffect, non-convert balances will now nag about data>metadata. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- To reproduce: dd if=/dev/zero bs=1048576 count=1 seek=4095 of=ra dd if=/dev/zero bs=1048576 count=1 seek=4095 of=rb mkfs.btrfs ra rb # defaults to -draid0 -mraid1 loset

Re: [PATCH v3 0/7] Chunk level degradable check

ain, not to add new members in btrfs_device, > but use a new structure extra_rw_degrade_errors, to record error when > sending down/waiting device. > > Sorry Dmitrii Tcvetkov and Adam Borowski, I'm afraid I can't add your > tested-by tags in v3, as the 4th and 4th patches have qu

[PATCH] btrfs: drop the nossd flag when remounting with -o ssd

The opposite case was already handled right in the very next switch entry. Reported-by: Hans van Kranenburg <hans.van.kranenb...@mendix.com> Signed-off-by: Adam Borowski <kilob...@angband.pl> --- Not sure if setting NOSSD should also disable SSD_SPREAD, there's currently no wa

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: 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: [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: [PATCH v2 3/4] btrfs: Add zstd support

On Tue, Jul 11, 2017 at 06:01:38AM +, Nick Terrell wrote: > On 7/10/17, 9:57 PM, "Nick Terrell" wrote: > > The problem is caused by a gcc-7 bug [1]. It miscompiles > > ZSTD_wildcopy(void *dst, void const *src, ptrdiff_t len) when len is 0. > > Sorry, my patch still triggered

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > On 7/6/17, 9:32 AM, "Adam Borowski" <kilob...@angband.pl> wrote: > > Got a reproducible crash on amd64: > > > > [98235.266511] BUG: unable to handle kernel paging request at &g

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: > On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > > On 7/6/17, 9:32 AM, "Adam Borowski" <kilob...@angband.pl> wrote: > > > Got a reproducible crash on amd64: > > >

Re: [PATCH v4 0/6] Chunk level degradable check

On Thu, Jul 13, 2017 at 02:50:10AM +0200, David Sterba wrote: > On Mon, Jul 10, 2017 at 09:11:50PM +0300, Dmitrii Tcvetkov wrote: > > Tested on top of current mainline master (commit > > af3c8d98508d37541d4bf57f13a984a7f73a328c). Didn't find any > > regressions. I've retested this yet again. No

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   >