One of my backup disks hit a btrfs bug yesterday, leaving me with a
forced readonly filesystem (see kernel trace below). This error is
reproducible, and happens on first access after mounting. This disk
receives snapshots (incrementally "ssh btrfs send -p | btrfs receive")
from several hosts on a
On 2015-07-09 14:26, Martin Steigerwald wrote:
Well I may try it for one of my BTRFS volumes in addition to the rsync
backup for now. I would like to give all options on command line, but well,
maybe it can completely replace my current script if I put everything in its
configuration.
One
tput linewise.
>
>>
>> Keep it simple and don't reimplement the wheel, for nice tabular
>> output we have the "column" command from util-linux:
>>
>> btrfs subvolume list -t | column -t
>>
>> Signed-off-by: Axel Burri <a...@tty0.ch>
While digging deeper into the "subvolume list" command, I found
some flaws which I'm addressing here:
1. The "parent id" seems to be a relict of old days.
btrfs-subvolume(8) states:
"If -p is given, then parent is added to the output between
ID and top level. The parent's ID may be used at
On 2015-10-04 16:34, Goffredo Baroncelli wrote:
> On 2015-10-04 05:37, Duncan wrote:
>> Goffredo Baroncelli posted on Sat, 03 Oct 2015 19:41:33 +0200 as
>> excerpted:
>>
>>> On 2015-10-03 12:09, Axel Burri wrote:
>>>>
>>>>
>>>> O
On 2015-10-05 17:42, Goffredo Baroncelli wrote:
> Hi Axel,
>
> On 2015-10-05 17:04, Axel Burri wrote:
> [...]
>> I still don't think it is wise to bloat things further just for printing
>> nice tables. My impression is that "btrfs subvolume list" is
>&g
On 2015-11-27 03:02, Duncan wrote:
>>> Then there's the security angle to consider. With the (basically,
>>> possibly modified as I suggested) flat layout, mounting something
>>> doesn't automatically give people in-tree access to nested subvolumes
>>> (subject to normal file permissions, of
(see links to patchset at end of mail)
While btrfs-progs offer the all-inclusive "btrfs" command, it gets
pretty cumbersome to restrict privileges to the subcommands. Common
approaches are to either setuid root for "/sbin/btrfs" (which is not
recommended at all), or to write special sudo rules
On 2017-08-23 14:07, Austin S. Hemmelgarn wrote:
> On 2017-08-22 13:41, Peter Grandi wrote:
> [ ... ]
>> This stupid point relies on ignoring that it is not mandatory to
>> mount the main volume, and that therefore "There is no fixed
>> relationship between the root directory inode of a subvolume
On 2017-05-05 19:03, Lewis Diamond wrote:
> Hi,
>
> I ran into a situation where my incremental backups using send|receive
> are failing after a full file system failure followed by restore from an
> external backup. The reason for the failures seem to be that the
> Received UUID of snapshots and
ume snapshot -r mysubvol.rw mysubvol
# btrfs subvolume delete mysubvol.rw
Instead of the second snapshot operation, this time you could also use
the (evil) command: "btrfs btrfs property set -ts mysnapshot ro true"
> On Thu, Sep 7, 2017 at 10:33 AM, Axel Burri <a...@tty0.ch> wrote
Having a received_uuid set on the source volume ("/home" in your case)
is indeed a bad thing when it comes to send/receive. You probably
restored a backup with send/receive, and made it read/write using "btrfs
property set -ts /home ro false". This is a an evil thing, as it leaves
received_uuid
On 2018-02-10 12:24, Tomasz Pala wrote:
> There is a serious flaw in btrfs subcommands handling. Since all of them
> are handled by single 'btrfs' binary, there is no way to create any
> protection against accidental data loss for (the only one I've found,
> but still DANGEROUS) 'btrfs subvolume
har **argv)
If they are defined non-static, we could probably simplify further and
add `-Wl,-eentry` flags (changing entry point from "main" to "entry").
With this, and if handle_command_group() was declared in some library
instead of btrfs.c, we would get rid of generated files complete
Install all $progs_install_splitcmd, and set appropriate linux file
capabilities(7) using setcap(8).
NOTE: while installing, group is hardcoded to "btrfs"! This needs
further discussion.
Signed-off-by: Axel Burri
---
Makefile| 36
Makef
Signed-off-by: Axel Burri
---
Makefile| 17 -
Makefile.install_setcap | 2 ++
splitcmd-gen.sh | 17 ++---
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/Makefile b/Makefile
index acf5a677..3f16434c 100644
--- a/Makefile
+++ b
Signed-off-by: Axel Burri
---
Makefile| 11 ++-
Makefile.install_setcap | 10 ++
splitcmd-gen.sh | 5 +
3 files changed, 17 insertions(+), 9 deletions(-)
create mode 100644 Makefile.install_setcap
diff --git a/Makefile b/Makefile
index 5a1e2747
eds to be
specified using the "fcaps" eclass anyways [5]).
References:
[1] https://www.spinics.net/lists/linux-btrfs/msg75736.html
[2] https://github.com/digint/btrbk
[3] https://github.com/digint/btrfs-progs-btrbk
[4] https://github.com/digint/btrfs-progs/tree/splitcmd-setcap
[
Another approach would be to generate the splitted commands in the
Makefile on-demand, which is probably not desired.
Signed-off-by: Axel Burri
---
btrfs-filesystem-usage.c | 23 +++
btrfs-qgroup-destroy.c | 23 +++
btrfs-receive.c| 23
Signed-off-by: Axel Burri
---
.gitignore | 9 +
1 file changed, 9 insertions(+)
diff --git a/.gitignore b/.gitignore
index 144ebb3b..299019e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,6 +42,15 @@ library-test-static
/fssum
testsuite-id
+btrfs-filesystem-usage
+btrfs-qgroup
On 29/08/2018 21.02, Austin S. Hemmelgarn wrote:
> On 2018-08-29 13:24, Axel Burri wrote:
>> This patch allows to build distinct binaries for specific btrfs
>> subcommands, e.g. "btrfs-subvolume-show" which would be identical to
>> "btrfs subvolume show"
In Reply to:
On 30/08/2018 04.38, Misono Tomohiro wrote:
>
> Hello,
>
> Not directly related this series and just FYI,
> I'm working to allow sub show/list to non-privileged user as long
> as he can access to the subvolume:
> https://www.spinics.net/lists/linux-btrfs/msg79285.html
>
> Hopefully
On 20/09/2018 10.32, Duncan wrote:
> Axel Burri posted on Thu, 20 Sep 2018 00:02:22 +0200 as excerpted:
>
>> Now not everybody wants to install these with fscaps or setuid, but it
>> might also make sense to provide "/usr/bin/btrfs-subvolume-{show,list}",
>> a
On 30/08/2018 19.23, Austin S. Hemmelgarn wrote:
> On 2018-08-30 13:13, Axel Burri wrote:
>> On 29/08/2018 21.02, Austin S. Hemmelgarn wrote:
>>> On 2018-08-29 13:24, Axel Burri wrote:
>>>> This patch allows to build distinct binaries for specific btrfs
>>&
thub.com/digint/gentoo/tree/btrfs-progs-separated/sys-fs/btrfs-progs-separated
[7] https://dev.tty0.ch/portage/digint-overlay.git
Axel Burri (4):
btrfs-progs: Makefile: create separated binaries for "btrfs"
subcommands; add fscaps declarations
btrfs-progs: remove unneeded depe
tuid
bit while installing.
Use --enable-btrfs-separated if you want to build (but not install)
all "btrfs-*.separated" binaries.
Signed-off-by: Axel Burri
---
Makefile| 36 +++-
Makefile.inc.in | 6 ++
configure.ac| 40 ++
" (comments) within the
c-file (for sysadmins / package maintainer).
- `make list-separated`: print a list of supported subcommands.
- `make list-fscaps`: print fscaps required for setcap(8). Note that
this list only covers some basic subcommands (the ones used by
btrbk-0.26.1 "
errors.
Signed-off-by: Axel Burri
---
Makefile | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Makefile b/Makefile
index 95db571b..362550c9 100644
--- a/Makefile
+++ b/Makefile
@@ -249,6 +249,15 @@ sc_cmds_all := $(sort $(foreach val,$(sc_map),$(firstword
$(subst @, ,$(val)
s in the source code
(especially by moving "int handle_command_group" functionality into a
separate compile unit).
This is not a problem, ignore these warnings when building object:
$(CC) -Wno-unused-function -Wno-unused-const-variable
Signed-off-by: Axel Burri
---
Makefile
29 matches
Mail list logo
