[btrfs-progs suspected BUG] Scrub info with Ubuntu-style subvol-as-root setup

Hi, Setup: btrfs root but Ubuntu style: /@/ with root=@ as a kernel boot option. Been using it happily for years; not even sure if Ubuntu still uses this system for btrfs installs. btrfs fs is a partition on my GPT HDD. My fstab contains subvol=@ as option on the btrfs line,

Re: btrfs-progs: btrfs convert v2

Vytautas D wrote on 2016/03/03 15:33 +: Hi Qu, thanks for your work on btrfs convert. Does your btrfs convert work ( namely https://www.spinics.net/lists/linux-btrfs/msg49719.html patches ) change any caveats described here ->

[PATCH] Show a warning message if one of highest objectid reaches its max value

- It's better to show a warning message for the exceptional case that one of highest objectid (in most case, inode number) reaches its max value, BTRFS_LAST_FREE_OBJECTID. Show this message only once to avoid filling dmesg with it. - EOVERFLOW is more proper return value for this case.

Byte comparison before hashing

First of all: Thanks for the great work on btrfs! How about taking only few bytes of data from each block and compare those, before attempting to hash? This way you could quickly discard blocks with really no similar data and hash only ones that matched the "first look" byte comparison? This could

Re: problems mounting subvolumes using nfs

On Fri, Mar 04, 2016 at 12:16:04AM +, niya levi wrote: > > i have a luks encrypted btrfs fileserver and have created this subvolume > structure on the server for my samba shares > > sambatop level > ---|homesubvolume > ---|---|gensubvolume

problems mounting subvolumes using nfs

i have a luks encrypted btrfs fileserver and have created this subvolume structure on the server for my samba shares sambatop level ---|homesubvolume ---|---|gensubvolume ---|---|---|s4usersubvolume ---|profilesubvolume

Re: how many chunk trees and extent trees present

On 04/18/2015 01:29 AM, David Sterba wrote: On Fri, Apr 17, 2015 at 09:19:11AM +, Hugo Mills wrote: In, some article i read that future there will be more chunk tree/ extent tree for single btrfs. Is this true. I recall, many moons ago, Chris saying that there probably wouldn't be.

Re: Byte comparison before hashing

Nikolai Viktorovich wrote on 2016/03/03 20:50 -0300: First of all: Thanks for the great work on btrfs! How about taking only few bytes of data from each block and compare those, before attempting to hash? This way you could quickly discard blocks with really no similar data and hash only ones

Re: Stray 4k extents with slow buffered writes

On Thu, Mar 03, 2016 at 02:13:09PM -0800, Liu Bo wrote: > On Thu, Mar 03, 2016 at 10:50:58PM +0100, Holger Hoffstätte wrote: > > On 03/03/16 21:47, Austin S. Hemmelgarn wrote: > > >> $mount | grep sdf > > >> /dev/sdf1 on /mnt/usb type btrfs > > >> (rw,relatime,space_cache=v2,subvolid=5,subvol=/)

Re: [RFC] Experimental btrfs encryption

The way btrfs encryption interacts with the keyring APIs is important, and "reconsidering later" will potentially represent an API/ABI break. Please keep it in mind. Yep. We would take considerable time to get the API frozen and integrated, as once its in, its there forever. So there are

Re: Stray 4k extents with slow buffered writes

On Thu, Mar 03, 2016 at 10:50:58PM +0100, Holger Hoffstätte wrote: > On 03/03/16 21:47, Austin S. Hemmelgarn wrote: > >> $mount | grep sdf > >> /dev/sdf1 on /mnt/usb type btrfs > >> (rw,relatime,space_cache=v2,subvolid=5,subvol=/) > > Do you still see the same behavior with the old space_cache

Re: [PATCH] Btrfs: fix loading of orphan roots leading to BUG_ON

On Thu, Mar 3, 2016 at 6:29 AM, Qu Wenruo wrote: > > > wrote on 2016/03/02 15:49 +: >> >> From: Filipe Manana >> >> When looking for orphan roots during mount we can end up hitting a >> BUG_ON() (at root-item.c:btrfs_find_orphan_roots()) if a log

Re: how many chunk trees and extent trees present

On Fri, Feb 26, 2016 at 09:29:29AM +0800, Qu Wenruo wrote: > > > David Sterba wrote on 2015/04/17 19:29 +0200: > > On Fri, Apr 17, 2015 at 09:19:11AM +, Hugo Mills wrote: > >>> In, some article i read that future there will be more chunk tree/ extent > >>> tree for single btrfs. Is this

Re: [PATCH] Btrfs: fix loading of orphan roots leading to BUG_ON

Duncan wrote on 2016/03/03 07:44 +: Qu Wenruo posted on Thu, 03 Mar 2016 14:26:45 +0800 as excerpted: Never heard the 2 release cycles principle, but seems to be not flex enough. From this point of view, every time Filipe(just an example, as he finds the most of bugs and corner case),

Re: [RFC] Experimental btrfs encryption

Qu Wenruo cn.fujitsu.com> writes: > > - As of now uses "user" keytype, I am still considering/ > >evaluating other key type such as logon. > > UI things can always be reconsidered later. > Never a big problem. This is not only a UI concern, but an API/ABI concern. To use eCryptFS as an

Re: [PATCH] Btrfs: fix loading of orphan roots leading to BUG_ON

On Thu, Mar 3, 2016 at 4:31 AM, Duncan <1i5t5.dun...@cox.net> wrote: > fdmanana posted on Wed, 02 Mar 2016 15:49:38 + as excerpted: > >> When looking for orphan roots during mount we can end up hitting a >> BUG_ON() (at root-item.c:btrfs_find_orphan_roots()) if a log tree is >> replayed and

btrfs-progs: btrfs convert v2

Hi Qu, thanks for your work on btrfs convert. Does your btrfs convert work ( namely https://www.spinics.net/lists/linux-btrfs/msg49719.html patches ) change any caveats described here -> https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3#Before_first_use i.e. does larger than 1 gb

Re: Again, no space left on device while rebalancing and recipe doesnt work

2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>: > > You're issue isn't the same, because all your space was allocated, > leaving only 1 MiB unallocated, which isn't normally enough to allocate a > new chunk to rewrite the data or metadata from the old chunks into. > > That's a known

Re: [PATCH] btrfs-convert: document -O|--features flag

On Wed, Mar 02, 2016 at 04:00:28PM +, Vytas Dauksa wrote: > Copy-pasted description found at mkfs.btrfs. I did not bother with > feature list as it seemed to be incomplete. Convert has smaller set of supported features, so it's better to leave the list out and refer to the -O list-all

[PATCH] fstests: remove call to _need_to_be_root from btrfs/118

From: Filipe Manana The function _need_to_be_root does not exists anymore as of commit 56ff01f471c9 ("xfstests: remove _need_to_be_root"). A v2 of the patch that added test btrfs/118 without calling this function was sent but not picked [1], instead v1 was picked. So fix

Stray 4k extents with slow buffered writes

Here's an observation that is not a bug (as in data corruption), just somewhat odd and unnecessary behaviour. It could be considered a performance or scalability bug. I've noticed that slow slow buffered writes create a huge number of unnecessary 4k sized extents. At first I wrote it off as odd

Re: Stray 4k extents with slow buffered writes

On 03/03/16 19:33, Liu Bo wrote: > On Thu, Mar 03, 2016 at 01:28:29PM +0100, Holger Hoffstätte wrote: (..) >> I've noticed that slow slow buffered writes create a huge number of >> unnecessary 4k sized extents. At first I wrote it off as odd buffering >> behaviour of the application (a download

Re: [PATCH] fstests: remove call to _need_to_be_root from btrfs/118

On Thu, Mar 03, 2016 at 07:32:57AM +, fdman...@kernel.org wrote: > From: Filipe Manana > > The function _need_to_be_root does not exists anymore as of commit > 56ff01f471c9 ("xfstests: remove _need_to_be_root"). > > A v2 of the patch that added test btrfs/118 without

Re: Stray 4k extents with slow buffered writes

On Thu, Mar 03, 2016 at 01:28:29PM +0100, Holger Hoffstätte wrote: > > Here's an observation that is not a bug (as in data corruption), just > somewhat odd and unnecessary behaviour. It could be considered a > performance or scalability bug. > > I've noticed that slow slow buffered writes

Re: Stray 4k extents with slow buffered writes

On 2016-03-03 14:53, Holger Hoffstätte wrote: On 03/03/16 19:33, Liu Bo wrote: On Thu, Mar 03, 2016 at 01:28:29PM +0100, Holger Hoffstätte wrote: (..) I've noticed that slow slow buffered writes create a huge number of unnecessary 4k sized extents. At first I wrote it off as odd buffering

Re: Stray 4k extents with slow buffered writes

On Thu, Mar 03, 2016 at 01:28:29PM +0100, Holger Hoffstätte wrote: > > Here's an observation that is not a bug (as in data corruption), just > somewhat odd and unnecessary behaviour. It could be considered a > performance or scalability bug. > > I've noticed that slow slow buffered writes

Re: incomplete conversion to RAID1?

Hi Duncan, > Of course either way assumes you don't run into some bug that will > prevent removal of that chunk, perhaps exactly the same one that kept it > from being removed during the normal raid1 conversion. If that happens, > the devs may well be interested in tracking it down, as I'm not

Re: Stray 4k extents with slow buffered writes

On 03/03/16 21:47, Austin S. Hemmelgarn wrote: >> $mount | grep sdf >> /dev/sdf1 on /mnt/usb type btrfs >> (rw,relatime,space_cache=v2,subvolid=5,subvol=/) > Do you still see the same behavior with the old space_cache format? > This appears to be an issue of space management and allocation, so >