On Fri, Jul 29, 2016 at 11:43:29AM -0400, Jeff Mahoney wrote:
> On 6/6/16 10:13 AM, Jeff Mahoney wrote:
> > On 6/6/16 7:47 AM, Adam Borowski wrote:
> >> Hi!
> >> I just got this thrice, in 4.7-rc1 and 4.7-rc2:
> >>
> >> [ 1836.672368] --
On Wed, Aug 03, 2016 at 08:56:01PM +0100, Graham Cobb wrote:
> Are there any btrfs commands (or APIs) to allow a script to create a
> list of all the extents referred to within a particular (mounted)
> subvolume? And is it a reasonably efficient process (i.e. doesn't
> involve backrefs and, prefer
On Thu, Aug 11, 2016 at 04:23:45PM -0400, Dave T wrote:
> 1. Can one discontinue using the compress mount option if it has been
> used previously?
The mount option applies only to newly written blocks, and even then only to
files that don't say otherwise (via chattr +c or +C, btrfs property, etc).
On Sun, Aug 28, 2016 at 07:50:42PM +0200, Christoph Anton Mitterer wrote:
> On Sun, 2016-08-28 at 11:35 -0600, Chris Murphy wrote:
> > I don't see evidence of them in the btrfs send file, so I don't think
> > csums are in the stream.
>
> hmm... isn't that kinda unfortunate not to make use of the i
On Sun, Sep 11, 2016 at 09:48:35PM +0200, Martin Steigerwald wrote:
> Hmm… I found this from being referred to by reading Debian wiki page on
> BTRFS¹.
>
> I use compress=lzo on BTRFS RAID 1 since April 2014 and I never found an
> issue. Steven, your filesystem wasn´t RAID 1 but RAID 5 or 6?
>
On Sat, Sep 17, 2016 at 01:02:18PM +0200, Stefan Malte Schumacher wrote:
> Concerning Testing: I only use it on desktops and home servers, which
> do not offer any services to the net. I am very fond of Debian and
> always use stable or even old-stable on work servers, but was finally
> to annoyed
Hi!
I just had the following splat in 4.8-rc6 for the third time in a week:
[413782.442899] BTRFS critical (device sda1): corrupt leaf, non-root leaf's
nritems is 0: block=692012023808,root=1, slot=0
[413782.453888] BTRFS info (device sda1): leaf 692012023808 total ptrs 0 free
space 16283
[41378
On Mon, Sep 19, 2016 at 07:21:47PM -0700, Liu Bo wrote:
> On Tue, Sep 20, 2016 at 03:39:27AM +0200, Adam Borowski wrote:
> > Hi!
> > I just had the following splat in 4.8-rc6 for the third time in a week:
>
> Sorry for the trouble, this is caused by my patch and here are two
Signed-off-by: Adam Borowski
---
Documentation/btrfs-scrub.asciidoc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/btrfs-scrub.asciidoc
b/Documentation/btrfs-scrub.asciidoc
index 40e793c..e88e684 100644
--- a/Documentation/btrfs-scrub.asciidoc
+++ b
On Sat, Sep 24, 2016 at 08:09:26PM +0200, Christoph Anton Mitterer wrote:
> On Sat, 2016-09-24 at 17:40 +0500, Roman Mamedov wrote:
> > Yes. IIRC the reasoning was that it's more difficult to track checksums
> > of data which is being overwritten in-place (as opposed to CoW).
> AFAIU it wouldn't be
On Sun, Sep 25, 2016 at 02:25:32AM +0300, Alexander Tomokhov wrote:
> Ok, so data checksumming does not remain for newly created empty files
> with No_COW attribute. I think it's an important trait of Btrfs behavior
> and should be added to wiki. So that users are informed that disabling
> CoW on
On Sun, Sep 25, 2016 at 05:44:30AM +, Duncan wrote:
> Adam Borowski posted on Sun, 25 Sep 2016 01:50:14 +0200 as excerpted:
> > Actually, it disables pretty much all btrfs features except for... CoW.
> >
> > You lose:
> > * checksums
> > * compression
>
On Thu, Sep 29, 2016 at 09:27:01AM +0200, Stefan Priebe - Profihost AG wrote:
> Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang:
> >>> I found that compress sometime report ENOSPC error even in 4.8-rc8,
> >>> currently
> >> I cannot confirm that as i do not have anough space to test this without
> >>
On Wed, Oct 12, 2016 at 01:19:37PM -0400, Zygo Blaxell wrote:
> On Wed, Oct 12, 2016 at 01:48:58PM +0800, Qu Wenruo wrote:
> > In fact, the _concept_ to solve such RMW behavior is quite simple:
> >
> > Make sector size equal to stripe length. (Or vice versa if you like)
> >
> > Although the imple
On Wed, Oct 12, 2016 at 05:10:18PM -0400, Zygo Blaxell wrote:
> On Wed, Oct 12, 2016 at 09:55:28PM +0200, Adam Borowski wrote:
> > On Wed, Oct 12, 2016 at 01:19:37PM -0400, Zygo Blaxell wrote:
> > > I had been thinking that we could inject "plug" extents to fill up
&
The code fails if the third section is missing (like "4.18") or is followed
by anything but "." or "-". This happens for example if we're not exactly
at a tag and CONFIG_LOCALVERSION_AUTO=n (which results in "4.18.5+").
Signed-off-by: Adam Borowski
-
616d374efa23).
Signed-off-by: Adam Borowski
---
v2: more eloquent description; root can't defrag RO on old kernels (unlike
dedupe)
v3: more eloquentier description; s/defrag_ro/defrag_open_mode/
cmds-filesystem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a
On Tue, Dec 04, 2018 at 01:17:04PM +0100, David Sterba wrote:
> On Fri, Nov 16, 2018 at 03:54:24PM +0800, Qu Wenruo wrote:
> > The only location is the following code:
> >
> > int level = path->lowest_level + 1;
> > BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL);
> > while(level < B
On Wed, Dec 05, 2018 at 06:28:25AM -0600, Goldwyn Rodrigues wrote:
> This is a support for DAX in btrfs.
Yay!
> I understand there have been previous attempts at it. However, I wanted
> to make sure copy-on-write (COW) works on dax as well.
btrfs' usual use of CoW and DAX are thoroughly in conf
On Wed, Dec 05, 2018 at 02:43:03PM +0200, Nikolay Borisov wrote:
> One question below though .
>
> > +++ b/fs/btrfs/super.c
> > @@ -739,6 +741,17 @@ int btrfs_parse_options(struct btrfs_fs_info *info,
> > char *options,
> > case Opt_user_subvol_rm_allowed:
> > btrf
On Wed, Dec 12, 2018 at 09:31:02PM -0600, Nathan Dehnel wrote:
> Is it possible/safe to replace a SATA drive in a btrfs RAID10 pool
> with an SAS drive?
For btrfs, a block device is a block device, it's not "racist".
You can freely mix and/or replace. If you want to, say, extend a SD
card with NB
On Fri, Dec 14, 2018 at 05:14:37AM +, Duncan wrote:
> Adam Borowski posted on Thu, 13 Dec 2018 08:29:05 +0100 as excerpted:
> > On Wed, Dec 12, 2018 at 09:31:02PM -0600, Nathan Dehnel wrote:
> >> Is it possible/safe to replace a SATA drive in a btrfs RAID10 pool with
On Sun, Dec 23, 2018 at 12:24:02AM +, Paul Jones wrote:
> > IMHO the more pertinent question is :
> >
> > If a file has portions which are not easily compressible does that imply all
> > future writes are also incompressible. IMO no, so I think what will be
> > prudent
> > is remove FORCE_COM
On Mon, Jan 28, 2019 at 03:23:28PM +, Supercilious Dude wrote:
> On Mon, 28 Jan 2019 at 01:18, Qu Wenruo wrote:
> >
> > So for current upstream kernel, there should be no major problem despite
> > write hole.
>
>
> Can you please elaborate on the implications of the write-hole? Does
> it mea
On Sun, Feb 17, 2019 at 06:35:25PM +0200, Boaz Harrosh wrote:
> On 15/02/19 00:06, Dave Chinner wrote:
> > So you're adding an interface that allows users to change the create
> > time of files without needing any privileges?
> > Inode create time is forensic metadata in XFS - information we use
At least in Debian, default build flags include -Werror=format-security,
for good reasons in most cases. Here, the string comes from strftime --
and though I don't suspect any locale would be crazy enough to have %X
include a '%' char, the compiler has no way to know that.
Sign
> On Mon, Jun 17, 2019 at 06:45:48PM +0200, Adam Borowski wrote:
> > It has a mandatory argument, thus it always crashed.
>
> Applied, thanks.
Seems like this has fallen through the cracks -- could you please re-apply?
--8x--8x--8x--8x--8x--8x--8x--8x--8x--8x--8x--8x--8x--8x--8x-
On Sat, Aug 03, 2019 at 12:09:28PM +0200, Ulli Horlacher wrote:
> I have RHEL 7 and CentOS 7.6 servers with kernel 3.10.0 and btrfs-progs v4.9.1
> Is btrfs there ready for production usage(*)?
Hell no!
It's a truly ancient kernel, from the times btrfs wasn't considered stable.
There's a lot of ba
On Fri, Aug 23, 2019 at 09:43:22AM +, Paul Jones wrote:
> > > Am Do., 22. Aug. 2019 um 16:41 Uhr schrieb Holger Hoffstätte
> > > :
> > > > but how does btrfs benefit from this compared to using crc32-intel?
> > >
> > > As i know, crc32c is as far as ~3x faster than xxhash. But xxHash was
> > >
On Mon, Aug 26, 2019 at 08:27:15AM -0400, Austin S. Hemmelgarn wrote:
> On 2019-08-23 13:08, Adam Borowski wrote:
> > the improved collision
> > resistance of xxhash64 is not a reason as if you intend to dedupe you want
> > a crypto hash so you don't need to verify.
&
Hi!
I'm afraid that asciidoctor 2.0 dropped support for docbook45. The
explanation given is here:
https://github.com/asciidoctor/asciidoctor/issues/3005
This makes btrfs-progs fail to build unless docs are off, with:
asciidoctor: FAILED: missing converter for backend 'docbook45'. Processing
abor
On Tue, Sep 24, 2019 at 04:26:53PM +0200, David Sterba wrote:
> On Tue, Sep 03, 2019 at 05:00:42PM +0200, Johannes Thumshirn wrote:
> > Add an option to mkfs to specify which checksum algorithm will be used for
> > the filesystem.
> >
> > Signed-off-by: Johannes Thumshirn
>
> I'll change the opt
On Sun, Feb 11, 2018 at 12:31:42PM +0300, Andrei Borzenkov wrote:
> 11.02.2018 04:02, Hans van Kranenburg пишет:
> >> - /dev/sda6 / btrfs
> >> rw,relatime,ssd,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot
> >> 0 0
> >
> > Note that changes on atime cause writes to metadata, which means
On Thu, Feb 15, 2018 at 12:15:49PM -0500, Ellis H. Wilson III wrote:
> In discussing the performance of various metadata operations over the past
> few days I've had this idea in the back of my head, and wanted to see if
> anybody had already thought about it before (likely, I would guess).
>
> It
On Sat, Mar 10, 2018 at 03:55:25AM +0100, Christoph Anton Mitterer wrote:
> Just wondered... was it ever planned (or is there some equivalent) to
> get support for btrfs in zerofree?
Do you want zerofree for thin storage optimization, or for security?
For the former, you can use fstrim; this is e
On Sat, Mar 10, 2018 at 07:37:22PM +0500, Roman Mamedov wrote:
> Note you can use it on HDDs too, even without QEMU and the like: via using LVM
> "thin" volumes. I use that on a number of machines, the benefit is that since
> TRIMed areas are "stored nowhere", those partitions allow for incredibly
On Sun, Mar 11, 2018 at 11:28:08PM +0700, Andreas Hild wrote:
> Following a physical disk failure of a RAID1 array, I tried to mount
> the remaining volume of a root partition with "-o degraded". For some
> reason it ended up as read-only as described here:
> https://btrfs.wiki.kernel.org/index.php
On Fri, Mar 30, 2018 at 10:42:10AM +0100, Pete wrote:
> I've just notice work going on to make rmdir be able to delete
> subvolumes. Is there an intent to allow ls -l to display directories as
> subvolumes?
That's entirely up to coreutils guys.
Meow!
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
--
To unsubscribe
On Mon, Apr 02, 2018 at 10:07:01PM +, Hugo Mills wrote:
> On Mon, Apr 02, 2018 at 06:03:00PM -0400, Fedja Beader wrote:
> > Is there some testing utility for this? Is there a way to extract this/tell
> > with a high enough certainty from datasheets/other material before purchase?
>
>Given
On Thu, Apr 26, 2018 at 04:01:29PM +0800, Anand Jain wrote:
> Balance args info is an important information to be reviewed on the
> system under audit. So this patch adds that.
This kept annoying me. Thanks a lot!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that!
⠈⠳
On Sun, Dec 03, 2017 at 01:45:45AM +, Duncan wrote:
> Tomasz Pala posted on Sat, 02 Dec 2017 18:18:19 +0100 as excerpted:
> >> I got ~500 small files (100-500 kB) updated partially in regular
> >> intervals:
> >>
> >> # du -Lc **/*.rrd | tail -n1
> >> 105Mtotal
>
> FWIW, I've no idea what
This link is replicated in most filesystems' config stanzas. Referring
to an archived version of that site is pointless as it mostly deals with
patches; user documentation is available elsewhere.
Signed-off-by: Adam Borowski
---
Sending this as one piece; if you guys would instead prefer
On Mon, Dec 18, 2017 at 03:28:14PM -0700, Chris Murphy wrote:
> On Mon, Dec 18, 2017 at 1:49 AM, Anand Jain wrote:
> > Agreed. IMO degraded-raid1-single-chunk is an accidental feature
> > caused by [1], which we should revert back, since..
> >- balance (to raid1 chunk) may fail if FS is near
Hi!
I got a reproducible infinite hang, reliably triggered by the testsuite of
"flatpak"; fails on at least 4.15-rc6, 4.9.75, and on another machine with
Debian's 4.14.2-1.
[580632.355107] INFO: task kworker/u8:2:11105 blocked for more than 120 seconds.
[580632.355120] Not tainted 4.14.0-1-a
On Sun, Jan 07, 2018 at 01:17:19PM +0200, Nikolay Borisov wrote:
> On 6.01.2018 07:10, Adam Borowski wrote:
> > Hi!
> > I got a reproducible infinite hang, reliably triggered by the testsuite of
> > "flatpak"; fails on at least 4.15-rc6, 4.9.75, and on another mac
On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote:
> On Sat, Jan 27, 2018 at 13:26:13 +0300, Andrei Borzenkov wrote:
>
> >> I just tested to boot with a single drive (raid1 degraded), even with
> >> degraded option in fstab and grub, unable to boot ! The boot process
> >> stop on initra
On Sat, Jan 27, 2018 at 03:36:48PM +0100, Goffredo Baroncelli wrote:
> I think that the real problem relies that the mounting a btrfs filesystem
> cannot be a responsibility of systemd (or whichever rc-system).
> Unfortunately in the past it was thought that it would be sufficient to
> assemble a
On Mon, Jan 29, 2018 at 09:54:04AM +0100, Tomasz Pala wrote:
> On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote:
>
> > systemd can't possibly need to know more information than a person
> > does in the exact same situation in order to do the right thing. No
> > human would wait 10 minute
Any use of a long option would crash.
Signed-off-by: Adam Borowski
---
cmds/send.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmds/send.c b/cmds/send.c
index b8e3ba12..3bfc69f5 100644
--- a/cmds/send.c
+++ b/cmds/send.c
@@ -496,7 +496,8 @@ static int cmd_send(const
Signed-off-by: Adam Borowski
---
CHANGES | 2 +-
Documentation/btrfs-balance.asciidoc | 2 +-
Documentation/btrfs-man5.asciidoc| 4 ++--
INSTALL | 2 +-
README.md| 2 +-
cmds/filesystem-usage.c
On Sat, Jan 16, 2021 at 10:39:51AM +0300, Andrei Borzenkov wrote:
> 15.01.2021 06:54, Zygo Blaxell пишет:
> > On the other hand, I'm in favor of deprecating the whole discard option
> > and going with fstrim instead. discard in its current form tends to
> > increase write wear rather than decrease
die("read(%lu): %m\n", off);
if (lseek(fd, off, SEEK_SET) != off)
die("lseek for write: %m\n");
if (write(fd, &b, 1) != 1)
die("write: %m\n");
}
return 0;
}
>From d040af09adb03daadbba4336700f40425a860320 Mon S
's no reason
to consider it a rw operation. Thus, let's check only whether the file
could have been opened rw. Such access control is still needed as
currently defrag can use extra disk space, and might trigger bugs.
Signed-off-by: Adam Borowski
---
fs/btrfs/ioctl.c | 3 ++-
1 file ch
eyond strerror().
Signed-off-by: Adam Borowski
---
fs/btrfs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 01c150b6ab62..e96e3c3caca1 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2943,7 +2943,7 @@ stati
On Mon, Jul 23, 2018 at 05:26:24PM +0200, David Sterba wrote:
> On Wed, Jul 18, 2018 at 12:08:59AM +0200, Adam Borowski wrote:
(Combined with as-folded)
| | btrfs: allow defrag on a file opened read-only that has rw permissions
| |
> > Requiring a rw descriptor conflicts both ways
On Wed, Aug 01, 2018 at 05:45:15AM +0200, MegaBrutal wrote:
> But there is still one question that I can't get over: if you store a
> database (e.g. MySQL), would you prefer having a BTRFS volume mounted
> with nodatacow, or would you just simply use ext4?
>
> I know that with nodatacow, I take aw
duped gets ETXTBUSY. The answer (as above) is to allow them to
> open the targets ro - root can already do this. There was a patch from
> Adam Borowski to fix this back in 2016
> The 2nd patch fixes our return code for permission denied to be
> EPERM. For some reason we're returning
On Mon, Aug 20, 2018 at 08:16:16AM -0400, Austin S. Hemmelgarn wrote:
> Also, slightly OT, but atimes are not where the real benefit is here for
> most people. No sane software other than mutt uses atimes (and mutt's use
> of them is not sane, but that's a different argument)
Right. There are tw
The code fails if the third section is missing (like "4.18") or is followed
by anything but "." or "-". This happens for example if we're not exactly
at a tag and CONFIG_LOCALVERSION_AUTO=n (which results in "4.18.5+").
Signed-off-by: Adam Borowski
-
Fixes EXTXBSY races.
Signed-off-by: Adam Borowski
---
cmds-filesystem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 06c8311b..4c9df69f 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -26,6 +26,7
On Sun, Sep 02, 2018 at 09:15:25PM -0600, Chris Murphy wrote:
> For > 10 years drive firmware handles bad sector remapping internally.
> It remaps the sector logical address to a reserve physical sector.
>
> NTFS and ext[234] have a means of accepting a list of bad sectors, and
> will avoid using
On Mon, Sep 03, 2018 at 02:01:21PM +0300, Nikolay Borisov wrote:
> On 3.09.2018 13:14, Adam Borowski wrote:
> > Fixes EXTXBSY races.
>
> You have to be more eloquent than that and explain at least one race
> condition.
If you try to defrag an executable that's currently
On Mon, Sep 03, 2018 at 02:04:23PM +0300, Nikolay Borisov wrote:
> On 3.09.2018 13:14, Adam Borowski wrote:
> > - fd = open(fpath, O_RDWR);
> > + fd = open(fpath, defrag_ro);
>
> Looking at the kernel code I think this is in fact incorrect, because
: Adam Borowski
---
v2: more eloquent description; root can't defrag RO on old kernels (unlike
dedupe)
cmds-filesystem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 06c8311b..17e992a3 100644
--- a/cmds-filesys
616d374efa23).
Signed-off-by: Adam Borowski
---
v2: more eloquent description; root can't defrag RO on old kernels (unlike
dedupe)
v3: more eloquentier description; s/defrag_ro/defrag_open_mode/
cmds-filesystem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a
On Fri, Sep 07, 2018 at 09:27:28AM +0530, Lakshmipathi.G wrote:
> > One question:
> > Why not ioctl_fideduperange?
> > i.e. you kill most of benefits from that ioctl - atomicity.
> >
> I plan to add fideduperange as an option too. User can
> choose between fideduperange and ficlonerange call.
>
>
On Thu, Sep 06, 2018 at 06:08:33AM -0400, Austin S. Hemmelgarn wrote:
> On 2018-09-06 03:23, Nathan Dehnel wrote:
> > So I guess my question is, does btrfs support atomic writes across
> > multiple files? Or is anyone interested in such a feature?
> >
> I'm fairly certain that it does not currentl
On Sat, Sep 08, 2018 at 08:45:47PM +, Martin Raiber wrote:
> Am 08.09.2018 um 18:24 schrieb Adam Borowski:
> > On Thu, Sep 06, 2018 at 06:08:33AM -0400, Austin S. Hemmelgarn wrote:
> >> On 2018-09-06 03:23, Nathan Dehnel wrote:
> >>> So I guess my question is, do
On Sun, Sep 23, 2018 at 11:54:12PM +0200, Hans van Kranenburg wrote:
> Two examples have been added, which use the new code. I would appreciate
> extra testing. Please try them and see if the reported numbers make sense:
>
> space_calculator.py
> ---
> Best to be initially describe
On Mon, Oct 08, 2018 at 02:03:44AM +0200, Hans van Kranenburg wrote:
> And yes, when promoting things like the new show_usage example to
> programs that are easily available, users will probably start parsing
> the output of them with sed and awk which is a total abomination and the
> absolute oppo
On Sun, Nov 04, 2018 at 06:29:06PM +, Duncan wrote:
> So do consider adding noatime to your mount options if you haven't done
> so already. AFAIK, the only /semi-common/ app that actually uses atimes
> these days is mutt (for read-message tracking), and then not for mbox, so
> you should be
On Fri, Mar 05, 2021 at 02:36:05PM +0100, David Sterba wrote:
> btrfs-progs version 5.11 have been released.
W: btrfs-progs source: absolute-symbolic-link-target-in-source
ci/images/ci-centos-7-x86_64/docker-build ->
/home/dsterba/labs/btrfs-progs/ci/images/docker-build
W: btrfs-progs source: ab
On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > DAX on btrfs has been attempted[1]. Of course, we could not
>
> But why? A completeness fetish? I don't understand why you decided
> to do this work.
* xfs ca
On Sat, Mar 13, 2021 at 11:24:00AM -0500, Neal Gompa wrote:
> On Sat, Mar 13, 2021 at 8:09 AM Adam Borowski wrote:
> >
> > On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
>
This is https://bugs.debian.org/985400
- Forwarded message from Claudius Heine -
Dear Maintainer,
I looked into the licenses of the btrfs-progs project and found that the
libbtrfsutils library is licensed under LGPL-3.0-or-later [1]
The `copyright` file does not show this this.
IANAL,
On Sun, Apr 11, 2021 at 12:10:34PM +0500, Roman Mamedov wrote:
> On Sat, 10 Apr 2021 17:06:22 -0600
> Chris Murphy wrote:
>
> > Right. The block device (partition containing the Btrfs file system)
> > must be exclusively used by one kernel, host or guest. Dom0 or DomU.
> > Can't be both.
> >
> >
The code fails if the third section is missing (like "4.18") or is followed
by anything but "." or "-". This happens for example if we're not exactly
at a tag and CONFIG_LOCALVERSION_AUTO=n (which results in "4.18.5+").
Signed-off-by: Adam Borowski
-
616d374efa23).
Signed-off-by: Adam Borowski
---
cmds-filesystem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index b8beec13..0eb052dc 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -26,6 +26,7 @@
#include
#include
On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
> This urgent patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/flush_super
> Which is based on v4.20.2.
>
> Before this patch, btrfs-progs writes to the fs has no barrier at all.
> All metadata and supe
On Tue, Mar 26, 2019 at 12:10:01PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote:
> > The dax option is restricted to non multi-device mounts.
> > dax interacts with the device directly instead of using bio, so
> > all bio-hooks which we use for mu
On Tue, Mar 26, 2019 at 02:09:08PM -0500, Goldwyn Rodrigues wrote:
> This patch set adds support for dax on the BTRFS filesystem.
This patchset doesn't seem to support MAP_SYNC, which is the usual way to
use (and detect) DAX. Basically, it requests for page faults to be
synchronous -- ie, when a
Used by userspace to detect DAX.
Signed-off-by: Adam Borowski
---
fs/btrfs/file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 196c8f37ff9d..8efdb040bc1d 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -16,6 +16,7 @@
#include
#include
[kdave: like the rest of btrfs+DAX patchset, this is WIP of course]
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index 196c8f37ff9d..8efdb040bc1d 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -16,6 +16,7 @@
> +#include
> + .mmap_supported_flags = MAP_SYNC,
With this, the
On Sat, Apr 20, 2019 at 12:46:16PM +0200, Juergen Sauer wrote:
> I wish a happy Easer Days before :)
Same to you!
> During my tests with BTRFS as Raid5 setup, I found a courious little
> "problem".
> Total devices 3 FS bytes used 9.98TiB
> devid1 size 9.09TiB used 4.99TiB pat
On Fri, May 17, 2019 at 09:07:03PM +0200, Johannes Thumshirn wrote:
> On Fri, May 17, 2019 at 08:36:23PM +0200, Diego Calleja wrote:
> > If btrfs needs an algorithm with good performance/security ratio, I would
> > suggest considering BLAKE2 [1]. It is based in the BLAKE algorithm that
> > made
On Thu, May 23, 2019 at 03:44:49PM +0200, Jan Kara wrote:
> On Mon 29-04-19 12:26:43, Goldwyn Rodrigues wrote:
> > From: Adam Borowski
> >
> > Used by userspace to detect DAX.
> > [rgold...@suse.com: Added CONFIG_FS_DAX around mmap_supported_flags]
>
> Why t
On Thu, May 23, 2019 at 10:24:28AM -0600, Chris Murphy wrote:
> On Thu, May 23, 2019 at 5:19 AM Austin S. Hemmelgarn
> > BTRFS explicitly requests write barriers to prevent that type of
> > reordering of writes from happening, and it's actually pretty unusual on
> > modern hardware for those write
It has a mandatory argument, thus it always crashed.
Signed-off-by: Adam Borowski
---
check/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/check/main.c b/check/main.c
index 731c21d3..b2f0c810 100644
--- a/check/main.c
+++ b/check/main.c
@@ -9923,7 +9923,7 @@ int
On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote:
> The permission check in vfs_dedupe_file_range() is too coarse - We
> only allow dedupe of the destination file if the user is root, or
> they have the file open for write.
>
> This effectively limits a non-root user from deduping their
On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > Right now we return EINVAL if a process does not have permission to dedupe a
> > file. This was an oversight on my part. EPERM gives a true description of
> > the natu
On Sun, May 13, 2018 at 06:16:53PM +, Mark Fasheh wrote:
> On Sat, May 12, 2018 at 04:49:20AM +0200, Adam Borowski wrote:
> > On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote:
> > > The permission check in vfs_dedupe_file_range() is too coarse - We
> > &g
On Wed, May 16, 2018 at 10:57:57AM +0300, Nikolay Borisov wrote:
> On 16.05.2018 05:51, Anand Jain wrote:
> > Balance args info is an important information to be reviewed for the
> > system audit. So this patch adds it to the kernel log.
> >
> > Example:
> >
> > -> btrfs bal start -dprofiles='rai
Hi!
Here's a patch to fix ETXTBSY races between defrag and exec -- similar to
what was just submitted for dedupe, even to the point of being followed by
a second patch that replaces EINVAL with EPERM.
As defrag is not something you're going to do on files you don't write, I
skipped complex rules a
's no reason
to consider it a rw operation. Thus, let's check only whether the file
could have been opened rw. Such access control is still needed as
currently defrag can use extra disk space, and might trigger bugs.
Signed-off-by: Adam Borowski
---
fs/btrfs/ioctl.c | 3 ++-
1 file ch
eyond strerror().
Signed-off-by: Adam Borowski
---
fs/btrfs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index b75db9d72106..ae6a110987a7 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2563,7 +2563,7 @@ stati
NOT FOR MERGING -- requires kernel versioning
Fixes EXTXBSY races.
Signed-off-by: Adam Borowski
---
cmds-filesystem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 30a50bf5..7eb6b7bb 100644
--- a/cmds-filesystem.c
+++ b/cmds
On Thu, Jun 28, 2018 at 03:04:43PM +0800, Qu Wenruo wrote:
> There is a reporter considering btrfs raid1 has a major design flaw
> which can't handle nodatasum files.
>
> Despite his incorrect expectation, btrfs indeed doesn't handle device
> generation mismatch well.
>
> This means if one device
On Wed, Jun 27, 2018 at 08:50:11PM +0200, waxhead wrote:
> Chris Murphy wrote:
> > On Thu, Jun 21, 2018 at 5:13 PM, waxhead wrote:
> > > According to this:
> > >
> > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf
> > > Page 4 , section 1.2
> > >
> > > It claims that BTRFS still ha
On Wed, Nov 02, 2016 at 09:29:26AM +, Hugo Mills wrote:
> On Wed, Nov 02, 2016 at 10:18:03AM +0100, Christian Völker wrote:
> > thanks for the quick reply. Regarding version- I prefer to use stable
> > Linux versionsand I am not going to upgrade just btrfs outside of
> > the verndors builds
They're not even documented anywhere, letting users with no recourse but
to RTFS. It's no big burden to output the bitfield as words.
Also, display unknown flags as hex.
Signed-off-by: Adam Borowski
---
fs/btrfs/relocation.c | 34 --
1 file c
1 - 100 of 268 matches
Mail list logo
