Re: your mail

[Tomasz Pala]

On Sun, Feb 18, 2018 at 10:28:02 +0100, Tomasz Pala wrote:

> I've already noticed this problem on February 10th:
> [btrfs-progs] coreutils-like -i parameter, splitting permissions for various 
> tasks
> 
> In short: not possible. Regular user can only create subvolumes.

Not possible "oficially". Axel Burri has replied with more helpful approach:
https://github.com/digint/btrfs-progs-btrbk

Unfortunately this issue was not picked up by any developer, so for now
we can only wait for splitting libbtrfsutil so this task could be easier.

-- 
Tomasz Pala 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Tomasz Pala]

On Sun, Feb 18, 2018 at 08:14:25 +, Tomasz Kłoczko wrote:

> For some reasons btrfs pool each volume is not displayed in mount and
> df output, and I cannot find how to display volumes/snapshots usage
> using btrfs command.

In general: not possible without enabling quotas, which in turn impact
snapshot performance significally.

btrfs quota enable /
btrfs quota rescan /
btrfs qgroup sh --sort=excl /

> So now I have many volumes and snapshots in my home directory, but to
> maintain all this I must use root permission. As non-root working in
> my own home which is separated btrfs volume it would be nice to have
> the possibility to delegate permission to create, destroy,
> send/receive, mount/umount etc. snapshots, volumes like it os possible
> on zfs.

I've already noticed this problem on February 10th:
[btrfs-progs] coreutils-like -i parameter, splitting permissions for various 
tasks

In short: not possible. Regular user can only create subvolumes.

> BTW: someone maybe started working on something like .zfs hidden
> directory functions which is in each zfs volume mountpoint?

In btrfs world this is done differently - don't put main (working) volume in the
root, but mount some branch by default, keeping all the subvolumes next
to it. I.e. don't:

@working_subvolume
@working_subvolume/snapshots

but:

@root_of_the_fs
@root_of_the_fs/working_subvolume
@root_of_the_fs/snapshots

In fact this is manual workaroud for the problem you've mentioned.

> Have few or few tenths snapshots is not so big deal but the same on
> scale few hundreds, thousands or more snapshots I think that would be
> really hard without something like hidden .btrfs/snapshots directory.

With few hundreds of subvolumes btrfs would fail miserably.

> After few years not using btrfs (because previously was quite
> unstable) It is really good to see that now I'm not able to crash it.

It's not crashing with LTS 4.4 and 4.9 kernels, many reports of various
crashes in 4.12, 4.14 and 4.15 were posted here. It is really hard to say,
which of the post-4.9 kernels have reliable btrfs.

-- 
Tomasz Pala 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Austin S. Hemmelgarn]

On 2016-09-01 12:44, Kyle Gates wrote:

-Original Message-
From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
ow...@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
Sent: Thursday, September 01, 2016 6:18 AM
To: linux-btrfs@vger.kernel.org
Subject: Re: your mail

On 2016-09-01 03:44, M G Berberich wrote:

Am Mittwoch, den 31. August schrieb Fennec Fox:

Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37

UTC

2016 x86_64 GNU/Linux
btrfs-progs v4.7

Data, single: total=30.01GiB, used=18.95GiB System, single:
total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B

{02:50} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
fennectech:
Sorry, try again.
[sudo] password for fennectech:
/: 99.8 GiB (107167244288 bytes) trimmed

{03:08} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
fennectech:
/: 99.9 GiB (107262181376 bytes) trimmed

  I ran these commands minutes after echother ane each time it is
trimming the entire free space

Anyone else seen this?   the filesystem is the root FS and is compressed


You should be very happy that it is trimming at all. Typical situation
on a used btrfs is

  # fstrim -v /
  /: 0 B (0 bytes) trimmed

even if there is 33G unused space ob the fs:

  # df -h /
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda296G   61G   33G  66% /


I think you're using an old kernel, this has been working since at least 4.5, 
but
was broken in some older releases.


M G is running 4.7.2
The problem is that all space has been allocated by block groups and fstrim 
will only work on unallocated space.
Yep, that would do so also, and this behavior really could be much 
better documented.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Jeff Mahoney]

On 9/1/16 12:44 PM, Kyle Gates wrote:
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
>> ow...@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
>>>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
>>>> 2016 x86_64 GNU/Linux
>>>> btrfs-progs v4.7
>>>>
>>>> Data, single: total=30.01GiB, used=18.95GiB System, single:
>>>> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
>>>> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
>>>>
>>>> {02:50} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> Sorry, try again.
>>>> [sudo] password for fennectech:
>>>> /: 99.8 GiB (107167244288 bytes) trimmed
>>>>
>>>> {03:08} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> /: 99.9 GiB (107262181376 bytes) trimmed
>>>>
>>>>   I ran these commands minutes after echother ane each time it is
>>>> trimming the entire free space
>>>>
>>>> Anyone else seen this?   the filesystem is the root FS and is compressed
>>>
>>> You should be very happy that it is trimming at all. Typical situation
>>> on a used btrfs is
>>>
>>>   # fstrim -v /
>>>   /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>>   # df -h /
>>>   Filesystem  Size  Used Avail Use% Mounted on
>>>   /dev/sda296G   61G   33G  66% /
>>>
>> I think you're using an old kernel, this has been working since at least 
>> 4.5, but
>> was broken in some older releases.
> 
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fstrim 
> will only work on unallocated space.

Historically it was the opposite problem.  My fixes made it so it would
work on unallocated space.  We probably need some debugging to see why
it's not discarding extents that are allocated as block groups but
unallocated within them.

-Jeff

> On my system all space has been allocated on my root filesystem so 0 B are 
> trimmed:
> kyle@home:~$  uname -a
> Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 
> 2016 x86_64 x86_64 x86_64 GNU/Linux
> kyle@home:~$  sudo btrfs fi show /
> Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
> Total devices 2 FS bytes used 13.44GiB
> devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
> devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
> kyle@home:~$  btrfs fi df /
> Data, RAID1: total=18.97GiB, used=12.98GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=1.00GiB, used=473.83MiB
> GlobalReserve, single: total=160.00MiB, used=0.00B
> kyle@home:~$  sudo fstrim -v /
> [sudo] password for kyle:
> /: 0 B (0 bytes) trimmed
> 
> But I do have space trimmed on my home filesystem:
> kyle@home:~$  sudo btrfs fi show /home/
> Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
> Total devices 2 FS bytes used 18.63GiB
> devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
> devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
> kyle@home:~$  btrfs fi df /home/
> Data, RAID1: total=27.00GiB, used=18.46GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=2.00GiB, used=168.62MiB
> GlobalReserve, single: total=64.00MiB, used=0.00B
> kyle@home:~$  sudo fstrim -v /home
> /home: 70 GiB (75092721664 bytes) trimmed
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: your mail

[M G Berberich]

Am Donnerstag, den 01. September schrieb Austin S. Hemmelgarn:
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> > > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> > > 2016 x86_64 GNU/Linux
> > > btrfs-progs v4.7
> > > 
> > > Data, single: total=30.01GiB, used=18.95GiB
> > > System, single: total=4.00MiB, used=16.00KiB
> > > Metadata, single: total=1.01GiB, used=422.17MiB
> > > GlobalReserve, single: total=144.00MiB, used=0.00B
> > > 
> > > {02:50} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > Sorry, try again.
> > > [sudo] password for fennectech:
> > > /: 99.8 GiB (107167244288 bytes) trimmed
> > > 
> > > {03:08} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > /: 99.9 GiB (107262181376 bytes) trimmed
> > > 
> > >   I ran these commands minutes after echother ane each time it is
> > > trimming the entire free space
> > > 
> > > Anyone else seen this?   the filesystem is the root FS and is compressed
> > 
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> > 
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> > 
> > even if there is 33G unused space ob the fs:
> > 
> >   # df -h /
> >   Filesystem  Size  Used Avail Use% Mounted on
> >   /dev/sda296G   61G   33G  66% /
> > 
> I think you're using an old kernel, this has been working since at least
> 4.5, but was broken in some older releases.

No, I’m always running a fairly up-to-date vanilla kernel on this
system. At the moment it’s:

  Linux hermione 4.7.2 #4 SMP PREEMPT Wed Aug 24 17:12:03 CEST 2016 x86_64 
GNU/Linux

I’m running kernels ≥ 4.5.0 since about April and I first reported this
problem at 7 Jul 2016 (Subject: fstrim problem/bug) probably with a
4.6.3 kernel.

MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Kyle Gates]

> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
> Sent: Thursday, September 01, 2016 6:18 AM
> To: linux-btrfs@vger.kernel.org
> Subject: Re: your mail
> 
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> >> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
> UTC
> >> 2016 x86_64 GNU/Linux
> >> btrfs-progs v4.7
> >>
> >> Data, single: total=30.01GiB, used=18.95GiB System, single:
> >> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
> >> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
> >>
> >> {02:50} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> Sorry, try again.
> >> [sudo] password for fennectech:
> >> /: 99.8 GiB (107167244288 bytes) trimmed
> >>
> >> {03:08} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> /: 99.9 GiB (107262181376 bytes) trimmed
> >>
> >>   I ran these commands minutes after echother ane each time it is
> >> trimming the entire free space
> >>
> >> Anyone else seen this?   the filesystem is the root FS and is compressed
> >
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> >
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> >
> > even if there is 33G unused space ob the fs:
> >
> >   # df -h /
> >   Filesystem  Size  Used Avail Use% Mounted on
> >   /dev/sda296G   61G   33G  66% /
> >
> I think you're using an old kernel, this has been working since at least 4.5, 
> but
> was broken in some older releases.

M G is running 4.7.2
The problem is that all space has been allocated by block groups and fstrim 
will only work on unallocated space.

On my system all space has been allocated on my root filesystem so 0 B are 
trimmed:
kyle@home:~$  uname -a
Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
kyle@home:~$  sudo btrfs fi show /
Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
Total devices 2 FS bytes used 13.44GiB
devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
kyle@home:~$  btrfs fi df /
Data, RAID1: total=18.97GiB, used=12.98GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=473.83MiB
GlobalReserve, single: total=160.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /
[sudo] password for kyle:
/: 0 B (0 bytes) trimmed

But I do have space trimmed on my home filesystem:
kyle@home:~$  sudo btrfs fi show /home/
Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
Total devices 2 FS bytes used 18.63GiB
devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
kyle@home:~$  btrfs fi df /home/
Data, RAID1: total=27.00GiB, used=18.46GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=2.00GiB, used=168.62MiB
GlobalReserve, single: total=64.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /home
/home: 70 GiB (75092721664 bytes) trimmed
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Austin S. Hemmelgarn]

On 2016-09-01 03:44, M G Berberich wrote:

Am Mittwoch, den 31. August schrieb Fennec Fox:

Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
2016 x86_64 GNU/Linux
btrfs-progs v4.7

Data, single: total=30.01GiB, used=18.95GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=422.17MiB
GlobalReserve, single: total=144.00MiB, used=0.00B

{02:50} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v /
[sudo] password for fennectech:
Sorry, try again.
[sudo] password for fennectech:
/: 99.8 GiB (107167244288 bytes) trimmed

{03:08} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v /
[sudo] password for fennectech:
/: 99.9 GiB (107262181376 bytes) trimmed

  I ran these commands minutes after echother ane each time it is
trimming the entire free space

Anyone else seen this?   the filesystem is the root FS and is compressed


You should be very happy that it is trimming at all. Typical situation
on a used btrfs is

  # fstrim -v /
  /: 0 B (0 bytes) trimmed

even if there is 33G unused space ob the fs:

  # df -h /
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda296G   61G   33G  66% /

I think you're using an old kernel, this has been working since at least 
4.5, but was broken in some older releases.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[M G Berberich]

Am Mittwoch, den 31. August schrieb Fennec Fox:
> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> 2016 x86_64 GNU/Linux
> btrfs-progs v4.7
> 
> Data, single: total=30.01GiB, used=18.95GiB
> System, single: total=4.00MiB, used=16.00KiB
> Metadata, single: total=1.01GiB, used=422.17MiB
> GlobalReserve, single: total=144.00MiB, used=0.00B
> 
> {02:50} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> Sorry, try again.
> [sudo] password for fennectech:
> /: 99.8 GiB (107167244288 bytes) trimmed
> 
> {03:08} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> /: 99.9 GiB (107262181376 bytes) trimmed
> 
>   I ran these commands minutes after echother ane each time it is
> trimming the entire free space
> 
> Anyone else seen this?   the filesystem is the root FS and is compressed

You should be very happy that it is trimming at all. Typical situation
on a used btrfs is

  # fstrim -v /
  /: 0 B (0 bytes) trimmed

even if there is 33G unused space ob the fs:

  # df -h /
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda296G   61G   33G  66% /


MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Chris Mason]

On Thu, Mar 01, 2012 at 01:58:14PM +0100, David Sterba wrote:
 On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote:
  I want to use btrfs defrag tool but before that i want to know how
  much the disk is fragmented. I have tried to use filefrag but it gives
  me FIBMAP:invalid argument for many times.
 
 The only way to trigger FIBMAP on btrfs is to run filefrag with -B
 option, but it should use FIEMAP by default and it works. With -v option
 it'll list all extents.

We actually disabled bmap to keep the swap code from remembering fixed
offsets for btrfs files.  The only way to get the mapping is with
fiemap.

The defrag ioctl won't bother defragging files that are not fragmented.

-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Hugo Mills]

On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
 Just wondering if/how one goes about getting the btrfs checksum of a given
 file.  Is there a way?

   Checksums are computed on individual 4k blocks, not on the whole
file. There's no explicit interface for retrieving checksums, but if
you understand the data structures, you can get hold of the checksums
for a file using the BTRFS_IOC_TREE_SEARCH ioctl.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- How deep will this sub go? Oh,  she'll go all the way to ---   
the bottom if we don't stop her.


signature.asc
Description: Digital signature

Re: your mail

[Hugo Mills]

   [Your Reply-to: header was screwed up, so I'm sending this again.

From: Ken D'Ambrosio k...@jots.org
Reply-to: File's...@jots.org, checksum?@jots.org

]

On Tue, Sep 20, 2011 at 04:35:40PM +0100, Hugo Mills wrote:
 On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
  Just wondering if/how one goes about getting the btrfs checksum of a given
  file.  Is there a way?
 
Checksums are computed on individual 4k blocks, not on the whole
 file. There's no explicit interface for retrieving checksums, but if
 you understand the data structures, you can get hold of the checksums
 for a file using the BTRFS_IOC_TREE_SEARCH ioctl.
 
Hugo.
 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- How deep will this sub go? Oh,  she'll go all the way to ---   
the bottom if we don't stop her.


signature.asc
Description: Digital signature