Re: [PATCH 3/3] btrfs: document extent mapping assumptions in checksum

On Tue, Nov 27, 2018 at 2:32 PM Nikolay Borisov wrote: > > On 27.11.18 г. 21:08 ч., Noah Massey wrote: > > On Tue, Nov 27, 2018 at 11:43 AM Nikolay Borisov wrote: > >> > >> On 27.11.18 г. 18:00 ч., Johannes Thumshirn wrote: > >>> Document why map_priv

Re: [PATCH 3/3] btrfs: document extent mapping assumptions in checksum

On Tue, Nov 27, 2018 at 11:43 AM Nikolay Borisov wrote: > > On 27.11.18 г. 18:00 ч., Johannes Thumshirn wrote: > > Document why map_private_extent_buffer() cannot return '1' (i.e. the map > > spans two pages) for the csum_tree_block() case. > > > > The current algorithm for detecting a page

Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs)

pshot package scheduling cleanups it's not ever automatically removed? > just google it, there is no mention of this behaviour > Il giorno mar 28 ago 2018 alle ore 19:07 Austin S. Hemmelgarn > ha scritto: > > > > On 2018-08-28 12:05, Noah Massey wrote: > > >

Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs)

On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn wrote: > > On 2018-08-28 11:27, Noah Massey wrote: > > On Tue, Aug 28, 2018 at 10:59 AM Menion wrote: > >> > >> [sudo] password for menion: > >> ID gen top level path > >&g

Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs)

On Tue, Aug 28, 2018 at 10:59 AM Menion wrote: > > [sudo] password for menion: > ID gen top level path > -- --- - > 257 600627 5 /@ > 258 600626 5 /@home > 296 599489 5 >

Re: [PATCH v2] btrfs: Add graceful handling of V0 extents

On Tue, Jun 26, 2018 at 12:02 PM David Sterba wrote: > > On Tue, Jun 26, 2018 at 04:57:36PM +0300, Nikolay Borisov wrote: > > Following the removal of the v0 handling code let's be courteous and > > print an error message when such extents are handled. In the cases > > where we have a transaction

Re: [PATCH] btrfs: Add more details while checking tree block

On Fri, Jun 22, 2018 at 12:32 PM Hans van Kranenburg wrote: > > On 06/22/2018 06:25 PM, Nikolay Borisov wrote: > > > > > > On 22.06.2018 19:17, Su Yue wrote: > >> > >> > >> > >>> Sent: Friday, June 22, 2018 at 11:26 PM > >>> From: "Hans van Kranenburg" > >>> To: "Nikolay Borisov" , "Su Yue" >

Re: send ioctl failed with -2

On Tue, May 8, 2018 at 1:44 PM, Nicolas Porcel wrote: > Hello, > > When I do a btrfs send, I get the following error code: > > # btrfs send mysnapshot > /dev/null > ERROR: send ioctl failed with -2: No such file or directory > Silly question, but is

Re: [PATCH 1/3] btrfs: qgroups, fix rescan worker running races

On Fri, Apr 27, 2018 at 11:56 AM, David Sterba wrote: > On Thu, Apr 26, 2018 at 03:23:49PM -0400, je...@suse.com wrote: >> From: Jeff Mahoney >> >> Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization) >> fixed the issue with

Re: [PATCH v2 1/2] btrfs: Separate space_info create/update

On Wed, May 17, 2017 at 4:55 PM, Jeff Mahoney <je...@suse.com> wrote: > On 5/17/17 4:52 PM, Noah Massey wrote: >> On Wed, May 17, 2017 at 4:34 PM, Nikolay Borisov <nbori...@suse.com> wrote: >>> >>> >>> On 17.05.2017 21:57, Noah Massey wrote: >&g

Re: [PATCH v2 1/2] btrfs: Separate space_info create/update

On Wed, May 17, 2017 at 4:34 PM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 17.05.2017 21:57, Noah Massey wrote: >> On Wed, May 17, 2017 at 11:07 AM, Nikolay Borisov <nbori...@suse.com> wrote: >>> Currently the struct space_info creation code is int

Re: [PATCH v2 1/2] btrfs: Separate space_info create/update

On Wed, May 17, 2017 at 11:07 AM, Nikolay Borisov wrote: > Currently the struct space_info creation code is intermixed in the > udpate_space_info function. There are well-defined points at which the we ^^^ update_space_info > actually want to create brand-new space_info

Re: [PATCH v2 2/2] btrfs: Refactor update_space_info

minor nitpicks in the comment On Wed, May 17, 2017 at 11:07 AM, Nikolay Borisov wrote: > Following the factoring out of the creation code udpate_space_info can only " code, update_space_info " > be called for already-existing space_info structs. ", which always succeeds"?

Re: [PATCH v2] btrfs-progs: send-dump: always print a space after path

On Wed, Apr 12, 2017 at 7:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Evan Danaher posted on Tue, 11 Apr 2017 12:33:40 -0400 as excerpted: > >> I was shocked to discover that 'btrfs receive --dump' doesn't print a >> space after long filenames, so it runs together into the metadata; for >>

Re: [PATCH] btrfs-progs: send-dump: always print a space after path

On Mon, Apr 10, 2017 at 8:09 PM, Evan Danaher wrote: > I was shocked to discover that 'btrfs receive --dump' doesn't print a > space after long filenames, so it runs together into the metadata; for > example: > > truncate

Re: Cross subvolume "cp --reflink"?

On Wed, Oct 19, 2016 at 12:52 PM, Andrei Borzenkov wrote: > I get "Failed to clone: Invalid cross-device link". Is it expected? Yes, you cannot cross a MOUNTPOINT boundary with reflink. Or, for that matter, btrfs subvolume snapshot. > Basically this is (on openSUSE TW which

Re: Issue: errno:28 (No space left on device)

On Tue, Aug 9, 2016 at 8:56 AM, Austin S. Hemmelgarn wrote: > On 2016-08-09 07:50, Thomas wrote: >> >> Hello! > > First things first: > Mailing lists are asynchronous. You will almost _never_ get an immediate > response, and will quite often not get a response for a few

Re: "No space left on device" and balance doesn't work

On Tue, Aug 9, 2016 at 7:16 AM, Austin S. Hemmelgarn wrote: > On 2016-08-09 05:50, MegaBrutal wrote: >> >> 2016-06-03 14:43 GMT+02:00 Austin S. Hemmelgarn : >>> >>> >>> Also, since you're on a new enough kernel, try 'lazytime' in the mount >>> options

[PATCH] btrfs-progs: doc: add missing newline in btrfs-convert

Signed-off-by: Noah Massey <noah.mas...@gmail.com> --- Documentation/btrfs-convert.asciidoc | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/btrfs-convert.asciidoc b/Documentation/btrfs-convert.asciidoc index 28f9a39..ab3577d 100644 --- a/Documentation/btrfs-convert.as

Re: WARNING: at /home/kernel/COD/linux/fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x247/0x2c0 [btrfs]

On Thu, Jun 9, 2016 at 10:52 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Fugou Nashi posted on Sun, 05 Jun 2016 10:12:31 +0900 as excerpted: > >> Hi, >> >> Do I need to worry about this? >> >> Thanks. >> >> Linux nakku 4.6.0-040600-generic #201605151930 SMP Sun May 15 23:32:59 >> UTC 2016 x86_64

Re: Can't remove read-only snapshot with immutable flag set

On Wednesday, June 8, 2016, cdlscpmv wrote: > > Hi! > > It happened that I set the immutable flag (via `chattr +i`) on a subvolume. > Then I made a read-only snapshot of that subvolume. Now I can't remove > this snapshot. > > #> btrfs subvolume delete my_snapshot >

Re: [PATCH 1/2] btrfs-progs: utils: Introduce new pseudo random API

On Wed, May 25, 2016 at 12:14 AM, Qu Wenruo wrote: > David has reported some quite chaos usage of pseudo random numbers. > Like using static srand seed, or even calling rand() without setting > seed correctly. > > The new pseudo random API will initialize the random seed

[PATCH] btrfs-progs: Adjust timing of safety delay countdown

When printing the countdown in the safety delay, the number should correspond to the number of seconds remaining to wait at the time the delay is printed. In other words, there should be a one second sleep after printing '1'. Signed-off-by: Noah Massey <noah.mas...@gmail.com> --- cmds-bal

Re: [PATCH] btrfs-progs: add safety delay before starting full balance

On Mon, May 2, 2016 at 4:33 AM, David Sterba wrote: > A short delay with a warning before starting a full balance should > improve usability. We have been getting reports from people who run full > balance after following some random advice and then get surprised by the >

[PATCH] btrfs-progs: build: fix static standalone utilities

commit b5e7979 "btrfs-progs: build: extend per-binary objects" allows the standalone utilities to link against object files shared with the main binary. However, the btrfs-*.static targets need to be adjusted to build against the static versions of the common files. Signed-off-by: N

Re: btrfs und lvm-cache?

On Wed, Dec 23, 2015 at 6:38 AM, Neuer User wrote: > Am 23.12.2015 um 12:21 schrieb Martin Steigerwald: >> Hi. >> >> As far as I understand this way you basically loose the RAID 1 semantics of >> BTRFS. While the data is redundant on the HDDs, it is not redundant on the >>

Re: cannot move ro-snapshot directly but indirectly works

On Fri, Nov 27, 2015 at 22:06 Christoph Anton Mitterer wrote: > > Hey. > > Not sure whether this is intended or not, but it feels at least > somewhat strange: > > Consider I have a readonly snapshot (the only subvol here): > /btrfs/snapshots/ro-snapshot > now I want to move

Re: [BUG] BTRFS: error in btrfs_run_delayed_refs:2821: errno=-5 IO failure

On Wed, Jul 8, 2015 at 10:01 AM, Chris Murphy li...@colorremedies.com wrote: The short version: btrfs convert and subsequent balance will eat an ext4 file system. I've reproduced this 6 for 6 times with both kernel 4.1 and 4.2rc1, but I get different back traces for the two kernels. Kernel

Re: btrfs replace seems to corrupt the file system

On Sun, Jun 28, 2015 at 2:02 PM, Mordechay Kaganer mkaga...@gmail.com wrote: To recover the old device, that's what i'm trying to do. Asked on IRC also, no reply. As stated above, the device passes btrfs check without errors but cannot mount because it complains about ongoing replace and the

Re: [PATCH 1/2] btrfs-progs: read_tree_block() and read_node_slot() cleanup.

On Mon, Jan 26, 2015 at 10:12 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote: Allow read_tree_block() and read_node_slot() to return error pointer. This should help caller to get more specified error number. For existing callers, change (!eb) judgmentt to (!extent_buffer_uptodate(eb)) to keep

Re: Moving snapshots

On Fri, Jan 23, 2015 at 5:05 AM, Matthias Urlichs matth...@urlichs.de wrote: Hello, how do I move a (read-only) snapshot? If you want to move a read-only snapshot to a different directory, '..' changes, and therefore is not a read-only operation. Simply creating another read-only snap from

fstrim on BTRFS

Hello, I am looking for some clarification on TRIM / SSD maintenance. The wiki [1] suggests periodic fstrim, but fstrim does not discard unallocated blocks[2]. Which makes sense, given that mkfs issues a device wide trim, so they shouldn't have data. But it seems like both a balance, and a