Re: [PATCH v2] Btrfs: remove confusing tracepoint in btrfs_add_reserved_bytes

On Wed, Sep 05, 2018 at 09:55:27AM +0800, Liu Bo wrote: > Here we're not releasing any space, but transferring bytes from > ->bytes_may_use to ->bytes_reserved. > > Signed-off-by: Liu Bo > --- > v2: Add missing commit log. I've enhanced the changlog a bit how the tracepoint got there.

Re: [PATCH v2] Btrfs: remove confusing tracepoint in btrfs_add_reserved_bytes

On 5.09.2018 04:55, Liu Bo wrote: > Here we're not releasing any space, but transferring bytes from > ->bytes_may_use to ->bytes_reserved. > > Signed-off-by: Liu Bo Reviewed-by: Nikolay Borisov > --- > v2: Add missing commit log. > > fs/btrfs/extent-tree.c | 4 > 1 file changed, 4

[PATCH v2] Btrfs: remove confusing tracepoint in btrfs_add_reserved_bytes

Here we're not releasing any space, but transferring bytes from ->bytes_may_use to ->bytes_reserved. Signed-off-by: Liu Bo --- v2: Add missing commit log. fs/btrfs/extent-tree.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index

[PATCH] Btrfs: remove confusing tracepoint in btrfs_add_reserved_bytes

Signed-off-by: Liu Bo --- fs/btrfs/extent-tree.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 41a02cbb5a4a..76ee5ebef2b9 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -6401,10 +6401,6 @@ static int

Re: [PATCH] btrfs: Get rid of the confusing btrfs_file_extent_inline_len()

On Wed, Jun 06, 2018 at 03:41:49PM +0800, Qu Wenruo wrote: > We used to call btrfs_file_extent_inline_len() to get the uncompressed > data size of an inlined extent. > > However this function is hiding evil, for compressed extent, it has no > choice but to directly read out ram_bytes from

[PATCH] btrfs: Get rid of the confusing btrfs_file_extent_inline_len()

We used to call btrfs_file_extent_inline_len() to get the uncompressed data size of an inlined extent. However this function is hiding evil, for compressed extent, it has no choice but to directly read out ram_bytes from btrfs_file_extent_item. While for uncompressed extent, it uses item size to

[PATCH 2/6] btrfs-progs: Get rid of the confusing btrfs_file_extent_inline_len()

(). For compressed extent, it's just calling btrfs_file_extent_ram_bytes(). However for uncompressed extent, it falls back to btrfs_file_extent_inline_item_len(), makes us unable to detect anything wrong in ram_bytes. [FIX] Just get rid of such confusing btrfs_file_extent_inline_len() function. Reported

Re: [PATCH] Btrfs: fix confusing worker helper info

On Wed, Sep 13, 2017 at 12:09:28PM -0600, Liu Bo wrote: > We've seen the following backtrace stack in ftrace or dmesg log, > > kworker/u16:10-4244 [000] 241942.480955: function: > btrfs_put_ordered_extent > kworker/u16:10-4244 [000] 241942.480956: kernel_stack: trace>

[PATCH] Btrfs: fix confusing worker helper info

We've seen the following backtrace stack in ftrace or dmesg log, kworker/u16:10-4244 [000] 241942.480955: function: btrfs_put_ordered_extent kworker/u16:10-4244 [000] 241942.480956: kernel_stack: => finish_ordered_fn (a0384475) => btrfs_scrubparity_helper

Re: [PATCH RFC] Btrfs: fix confusing worker helper info

On Fri, Sep 08, 2017 at 03:34:45PM -0600, Liu Bo wrote: > We've seen the following backtrace stack in ftrace or dmesg log, > > kworker/u16:10-4244 [000] 241942.480955: function: > btrfs_put_ordered_extent > kworker/u16:10-4244 [000] 241942.480956: kernel_stack: trace>

[PATCH RFC] Btrfs: fix confusing worker helper info

We've seen the following backtrace stack in ftrace or dmesg log, kworker/u16:10-4244 [000] 241942.480955: function: btrfs_put_ordered_extent kworker/u16:10-4244 [000] 241942.480956: kernel_stack: => finish_ordered_fn (a0384475) => btrfs_scrubparity_helper

Re: Fwd: confusing "no space left" -- how to troubleshoot and "be prepared"?

On Thu, 18 May 2017, Peter Becker wrote: > I'm not sure if this would be helpfull but can you post the output > from this script? > cd /tmp > wget https://raw.githubusercontent.com/kdave/btrfs-progs/master/btrfs-debugfs > chmod +x btrfs-debugfs > stats=$(sudo ./btrfs-debugfs -b /) > ... Thank

Fwd: confusing "no space left" -- how to troubleshoot and "be prepared"?

2017-05-18 15:41 GMT+02:00 Yaroslav Halchenko : > > our python-based program crashed with > > File > "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/gitdb/stream.py", > line 695, in write > os.write(self._fd, data) > OSError: [Errno 28] No

confusing "no space left" -- how to troubleshoot and "be prepared"?

our python-based program crashed with File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/gitdb/stream.py", line 695, in write os.write(self._fd, data) OSError: [Errno 28] No space left on device but as far as I could see there still should be both data and

Re: Confusing output from fi us/df

On Mon, Jun 20, 2016 at 5:30 PM, Marc Grondin wrote: > Metadata,single: Size:3.00GiB, Used:1.53GiB Read this as: 3GiB of space on the device is reserved for metadata block group, and 1.53GiB of that is being used. The reservation means that this space can't be used for

Re: Confusing output from fi us/df

Hans van Kranenburg posted on Tue, 21 Jun 2016 02:25:20 +0200 as excerpted: > On 06/21/2016 01:30 AM, Marc Grondin wrote: >> >> I have a btrfs filesystem ontop of a 4x1tb mdraid raid5 array and I've >> been getting confusing output on metadata usage. Seems that even tho >

Re: Confusing output from fi us/df

On 2016/06/21 8:30, Marc Grondin wrote: > Hi everyone, > > > I have a btrfs filesystem ontop of a 4x1tb mdraid raid5 array and I've > been getting confusing output on metadata usage. Seems that even tho > both data and metadata are in single profile metadata is reporting

Re: Confusing output from fi us/df

Hi, On 06/21/2016 01:30 AM, Marc Grondin wrote: I have a btrfs filesystem ontop of a 4x1tb mdraid raid5 array and I've been getting confusing output on metadata usage. Seems that even tho both data and metadata are in single profile metadata is reporting double the space(as if it was in dupe

Confusing output from fi us/df

Hi everyone, I have a btrfs filesystem ontop of a 4x1tb mdraid raid5 array and I've been getting confusing output on metadata usage. Seems that even tho both data and metadata are in single profile metadata is reporting double the space(as if it was in dupe profile) root@thebeach /h/marcg

Re: btrfs-progs confusing message

On 04/21/2016 04:02 AM, Austin S. Hemmelgarn wrote: > On 2016-04-20 16:23, Konstantin Svist wrote: >> Pretty much all commands print out the usage message when no device is >> specified: >> >> [root@host ~]# btrfs scrub start >> btrfs scrub start: too few arguments >> usage: btrfs scrub start

Re: btrfs-progs confusing message

On 2016-04-20 16:23, Konstantin Svist wrote: Pretty much all commands print out the usage message when no device is specified: [root@host ~]# btrfs scrub start btrfs scrub start: too few arguments usage: btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] | ... However, balance

btrfs-progs confusing message

Pretty much all commands print out the usage message when no device is specified: [root@host ~]# btrfs scrub start btrfs scrub start: too few arguments usage: btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] | ... However, balance doesn't [root@host ~]# btrfs balance start

Re: confusing mountinfo output when bind-mounting files

6 x86_64 x86_64 x86_64 GNU/Linux The issue here is that the "subvol=" mount option for the target of the bind mount is "/file" when no such subvolume actually exists. Is this intended? It's confusing to say the least, but seems like a bug to me. Since btrfs mount subvol= i

Re: confusing mountinfo output when bind-mounting files

-progs v4.4 > > root@criu2:/tmp# uname -a > > Linux criu2 4.4.0-8-generic #23-Ubuntu SMP Wed Feb 24 20:45:30 UTC 2016 > > x86_64 x86_64 x86_64 GNU/Linux > > > > The issue here is that the "subvol=" mount option for the target of the bind > > mount is &q

Re: confusing mountinfo output when bind-mounting files

x86_64 GNU/Linux > > The issue here is that the "subvol=" mount option for the target of the bind > mount is "/file" when no such subvolume actually exists. Is this > intended? It's confusing to say the least, but seems like a bug to me. Since btrfs mount subvol

confusing mountinfo output when bind-mounting files

root@criu2:/tmp# uname -a Linux criu2 4.4.0-8-generic #23-Ubuntu SMP Wed Feb 24 20:45:30 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux The issue here is that the "subvol=" mount option for the target of the bind mount is "/file" when no such subvolume actually exists. Is this i

Re: [PATCH 3/4] btrfs-progs: replace a confusing raw number with a macro

On Thu, Jul 17, 2014 at 10:40:38AM +0800, Gui Hecheng wrote: The raw number 36 for the uuid string length is somewhat confusing, use a macro to define replace it. There's the BTRFS_UUID_UNPARSED_SIZE macro, please use it instead to avoid duplicate definitions. -- To unsubscribe from this list

Re: [PATCH 3/4] btrfs-progs: replace a confusing raw number with a macro

On Tue, Jul 29, 2014 at 02:16:14PM +0200, David Sterba wrote: On Thu, Jul 17, 2014 at 10:40:38AM +0800, Gui Hecheng wrote: The raw number 36 for the uuid string length is somewhat confusing, use a macro to define replace it. There's the BTRFS_UUID_UNPARSED_SIZE macro, please use it instead

Re: [PATCH 3/4] btrfs-progs: replace a confusing raw number with a macro

On Tue, 2014-07-29 at 14:19 +0200, David Sterba wrote: On Tue, Jul 29, 2014 at 02:16:14PM +0200, David Sterba wrote: On Thu, Jul 17, 2014 at 10:40:38AM +0800, Gui Hecheng wrote: The raw number 36 for the uuid string length is somewhat confusing, use a macro to define replace

[PATCH 3/4] btrfs-progs: replace a confusing raw number with a macro

The raw number 36 for the uuid string length is somewhat confusing, use a macro to define replace it. Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com --- cmds-scrub.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/cmds-scrub.c b/cmds-scrub.c index a604b25..03eb9ba

Re: Confusing output of btrfs fi df

So try this one: btrfs balance start -musage=0 -v I fear that didn't work too. mars:/mnt # btrfs balance start -musage=0 -v btrfs/ Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=0 SYSTEM (flags 0x2): balancing, usage=0 Done, had to relocate

Re: Confusing output of btrfs fi df

On Mon, Apr 28, 2014 at 01:57:02PM +0200, Stefan Malte Schumacher wrote: So try this one: btrfs balance start -musage=0 -v I fear that didn't work too. mars:/mnt # btrfs balance start -musage=0 -v btrfs/ Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2):

Re: Confusing output of btrfs fi df

Hi Stefan, On Sat, Apr 26, 2014 at 11:28 PM, Chris Murphy li...@colorremedies.com wrote: They're harmless -- it's a side-effect of the way that mkfs works. They'll go away if you balance them: btrfs balance start -dprofiles=single -mprofiles=single -sprofiles=single /mountpoint btrfs

Re: Confusing output of btrfs fi df

Hello Chris and Duncan: I tried both your suggestions but unfortunately without success. Here is the output: mars:~ # btrfs balance start -susage=0 -f -v /mnt/btrfs/ Dumping filters: flags 0xa, state 0x0, force is on SYSTEM (flags 0x2): balancing, usage=0 Done, had to relocate 0 out of 2708

Re: Confusing output of btrfs fi df

Stefan Malte Schumacher posted on Sun, 27 Apr 2014 17:37:26 +0200 as excerpted: Chris and Duncan: I tried both your suggestions but unfortunately without success. Here is the output: mars:~ # btrfs balance start -susage=0 -f -v /mnt/btrfs/ Dumping filters: flags 0xa, state 0x0, force is on

Confusing output of btrfs fi df

Hello Yesterday I created a btrfs-filesystem on two disk, using raid1 for data and metadata. I then mounted it and rsynced several TB of data onto it. mkfs.btrfs -m raid1 -d raid1 /dev/sdf /dev/sdg The command btrfs fi df /mnt/btrfs result in the following output: Data, RAID1: total=2.64TiB,

Re: Confusing output of btrfs fi df

On Sat, Apr 26, 2014 at 04:09:15PM +0200, Stefan Malte Schumacher wrote: Hello Yesterday I created a btrfs-filesystem on two disk, using raid1 for data and metadata. I then mounted it and rsynced several TB of data onto it. mkfs.btrfs -m raid1 -d raid1 /dev/sdf /dev/sdg The command

Re: Confusing output of btrfs fi df

They're harmless -- it's a side-effect of the way that mkfs works. They'll go away if you balance them: btrfs balance start -dprofiles=single -mprofiles=single -sprofiles=single /mountpoint btrfs refused this command, I had to pass --force to execute it. It exited with this:Done,

Re: Confusing output of btrfs fi df

On Apr 26, 2014, at 12:18 PM, Stefan Malte Schumacher s.schumac...@netcologne.de wrote: They're harmless -- it's a side-effect of the way that mkfs works. They'll go away if you balance them: btrfs balance start -dprofiles=single -mprofiles=single -sprofiles=single /mountpoint

Re: Confusing output of btrfs fi df

Chris Murphy posted on Sat, 26 Apr 2014 15:28:03 -0600 as excerpted: btrfs balance start -dprofiles=single -mprofiles=single -sprofiles=single /mountpoint After that btrfs fi df shows the following: Data, RAID1: total=2.64TiB, used=2.22TiB System, RAID1: total=8.00MiB, used=380.00KiB

confusing snapshot error

ERROR: cannot snapshot '/home' - Read-only file system The above error occurs when a read-only snapshot already exists. I think it would be better if the target name had to be fully qualified and gave an error path already exists or something similar. While the current behavior mimics the

[PATCH 08/11, RESEND] btrfs-progs: btrfs-select-super output is confusing when it fails

Trivial patch: ./btrfs-progs/btrfs-select-super -s 0 /dev/sdc using SB copy 0, bytenr 65536 No valid Btrfs found on /dev/sdc Open ctree failed The line 'using..' is confusing which gives an indication that command is successful This patch will avoid that when command fails Signed-off-by: Anand

Re: [PATCH RFC] Btrfs: fix confusing edquot happening case

-by: Wang Shilong wangsl-f...@cn.fujitsu.com --- This confusing edquot may also happen after Jan's qgroup rescan has been implemented. --- fs/btrfs/qgroup.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index b44124d..0178223

Re: [PATCH RFC] Btrfs: fix confusing edquot happening case

-by: Wang Shilong wangsl-f...@cn.fujitsu.com --- This confusing edquot may also happen after Jan's qgroup rescan has been implemented. --- fs/btrfs/qgroup.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index b44124d..0178223

Re: [PATCH RFC] Btrfs: fix confusing edquot happening case

reservation. Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com --- This confusing edquot may also happen after Jan's qgroup rescan has been implemented. --- fs/btrfs/qgroup.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c

[PATCH V2] Btrfs: fix confusing edquot happening case

From: Wang Shilong wangsl-f...@fujitsu.com Step to reproduce: mkfs.btrfs disk mount disk mnt dd if=/dev/zero of=/mnt/data bs=1M count=10 sync btrfs quota enable mnt btrfs qgroup create 0/5 mnt btrfs qgroup limit 5M 0/5 mnt rm -f

Re: [PATCH V2] Btrfs: fix confusing edquot happening case

I am sorry, please ignore this…I will resend it.. From: Wang Shilong wangsl-f...@fujitsu.com Step to reproduce: mkfs.btrfs disk mount disk mnt dd if=/dev/zero of=/mnt/data bs=1M count=10 sync btrfs quota enable mnt btrfs qgroup create 0/5 mnt

[PATCH V2 RESEND] Btrfs: fix confusing edquot happening case

From: Wang Shilong wangsl-f...@cn.fujitsu.com Step to reproduce: mkfs.btrfs disk mount disk mnt dd if=/dev/zero of=/mnt/data bs=1M count=10 sync btrfs quota enable mnt btrfs qgroup create 0/5 mnt btrfs qgroup limit 5M 0/5 mnt rm -f

[PATCH 8/9] btrfs-progs: btrfs-select-super output is confusing when it fails

Trivial patch: ./btrfs-progs/btrfs-select-super -s 0 /dev/sdc using SB copy 0, bytenr 65536 No valid Btrfs found on /dev/sdc Open ctree failed The line 'using..' is confusing which gives an indication that command is successful This patch will avoid that when command fails Signed-off-by: Anand

Confusing...

After completing an installation of Ubuntu 11.04 with a separate /boot partition and BTRFS as the main filesystem (Ubuntu creates subvolumes for / and /home). sda1 being the GPT stuff sda2 being most of the disk as BTRFS sda3 being /boot sda4 being swap sdb having an identical partition