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.
> >
> >
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 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:
>
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 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 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
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 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
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 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.
&
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 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 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-
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
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 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
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 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 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
[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
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
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
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 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
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
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
-
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
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, 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 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 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 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 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 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
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 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 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, 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 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 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 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.
>
>
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
: 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
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
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 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
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 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
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 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
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
'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
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
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 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
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
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
'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
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
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
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 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 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 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 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 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 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 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 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 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 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 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
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 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 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
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 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
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 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
On Tue, Nov 28, 2017 at 08:51:07AM +0800, Qu Wenruo wrote:
> On 2017年11月27日 22:22, David Sterba wrote:
> > On Mon, Nov 27, 2017 at 02:23:49PM +0100, Adam Borowski wrote:
> >> On 4.15-rc1, I get the following failure:
> >>
> >> BTRFS critical (device sda1): corr
Hi!
On 4.15-rc1, I get the following failure:
BTRFS critical (device sda1): corrupt leaf: root=1 block=3820662898688
slot=43 ino=35691 file_offset=0, invalid ram_bytes for uncompressed inline
extent, have 134 expect 281474976710677
Repeatable every boot attempt. 4.14 and earlier boot fine; btrfs
On Fri, Nov 17, 2017 at 08:19:11PM -0700, Chris Murphy wrote:
> On Fri, Nov 17, 2017 at 8:41 AM, Nazar Mokrynskyi
> wrote:
>
> >> [551049.038718] BTRFS warning (device dm-2): checksum error at logical
> >> 470069460992 on dev
> >> /dev/mapper/luks-bd5dd3e7-ad80-405f-8dfd-752f2b870f93-part1, se
On Tue, Nov 14, 2017 at 10:36:22AM +0200, Klaus Agnoletti wrote:
> I used to have 3x2TB in a btrfs in raid0. A few weeks ago, one of the
^
> 2TB disks started giving me I/O errors in dmesg like this:
>
> [388659.188988] Add. Sense: Unrecovered read error -
On Sat, Nov 04, 2017 at 09:26:36AM +0300, Andrei Borzenkov wrote:
> 04.11.2017 07:49, Adam Borowski пишет:
> > On Fri, Nov 03, 2017 at 06:15:53PM -0600, Chris Murphy wrote:
> >> Ancient bug, still seems to be a bug.
> >> https://bugzilla.redhat.com/show_bug.cgi?id=90
On Fri, Nov 03, 2017 at 06:15:53PM -0600, Chris Murphy wrote:
> Ancient bug, still seems to be a bug.
> https://bugzilla.redhat.com/show_bug.cgi?id=906591
>
> The issue is that updatedb by default will not index bind mounts, but
> by default on Fedora and probably other distros, put /home on a
> s
On Fri, Nov 03, 2017 at 04:03:44PM -0600, Chris Murphy wrote:
> On Tue, Oct 31, 2017 at 5:28 AM, Austin S. Hemmelgarn
> wrote:
>
> > If you're running on an SSD (or thinly provisioned storage, or something
> > else which supports discards) and have the 'discard' mount option enabled,
> > then the
On Wed, Oct 25, 2017 at 03:23:11PM +0200, David Sterba wrote:
> On Sat, Oct 21, 2017 at 06:49:01PM +0200, Adam Borowski wrote:
> > Many compressors do assign a meaning to level 0: either null compression or
> > the lowest possible level. This differs from our "unset thus defau
On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote:
> - Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.dun...@cox.net:
> > Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
> >
> >> Is it generally possible to restore a btrfs partition from a tape backup
> >> ?
> >
Many compressors do assign a meaning to level 0: either null compression or
the lowest possible level. This differs from our "unset thus default".
Thus, let's not unnecessarily confuse users.
Signed-off-by: Adam Borowski
---
fs/btrfs/super.c | 4 +++-
1 file changed, 3 i
On Wed, Oct 18, 2017 at 07:30:55AM -0400, Austin S. Hemmelgarn wrote:
> On 2017-10-17 16:21, Adam Borowski wrote:
> > > > It's a single-device filesystem, thus disconnects are obviously fatal.
> > > > But,
> > > > they never caused even
On Tue, Oct 17, 2017 at 03:19:09PM -0400, Austin S. Hemmelgarn wrote:
> On 2017-10-17 13:06, Adam Borowski wrote:
> > On Tue, Oct 17, 2017 at 08:40:20AM -0400, Austin S. Hemmelgarn wrote:
> > > On 2017-10-17 07:42, Zoltan wrote:
> > > > On Tue, Oct 17, 2017 at
On Tue, Oct 17, 2017 at 08:40:20AM -0400, Austin S. Hemmelgarn wrote:
> On 2017-10-17 07:42, Zoltan wrote:
> > On Tue, Oct 17, 2017 at 1:26 PM, Austin S. Hemmelgarn
> > wrote:
> >
> > > I forget sometimes that people insist on storing large volumes of data on
> > > unreliable storage...
> >
> >
On Mon, Oct 16, 2017 at 01:27:40PM -0400, Austin S. Hemmelgarn wrote:
> On 2017-10-16 12:57, Zoltan wrote:
> > On Mon, Oct 16, 2017 at 1:53 PM, Austin S. Hemmelgarn wrote:
> In an ideal situation, scrubbing should not be an 'only if needed' thing,
> even for a regular array that isn't dealing with
On Tue, Sep 26, 2017 at 11:33:19PM +0500, Roman Mamedov wrote:
> On Tue, 26 Sep 2017 16:50:00 + (UTC)
> Ferry Toth wrote:
>
> > https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
> > raid&num=2
> >
> > I think it might be idle hopes to think bcache can be used as a ssd cach
On Wed, Sep 13, 2017 at 08:21:01AM -0400, Austin S. Hemmelgarn wrote:
> On 2017-09-12 17:13, Adam Borowski wrote:
> > On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote:
> > > On 2017-09-12 16:00, Adam Borowski wrote:
> > > > Noted. Both Marat'
From: David Sterba
Preliminary support for setting compression level for zlib, the
following works:
$ mount -o compess=zlib # default
$ mount -o compess=zlib0# same
$ mount -o compess=zlib9# level 9, slower sync, less data
$ mount -o compess=zlib1
1 - 100 of 268 matches
Mail list logo
