Adam Borowski posted on Sun, 25 Sep 2016 01:50:14 +0200 as excerpted:
> 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
Signed-off-by: Nicholas D Steeves
---
Documentation/btrfs-check.asciidoc | 2 +-
Documentation/btrfs-device.asciidoc | 2 +-
Documentation/btrfs-man5.asciidoc | 2 +-
Documentation/btrfs-scrub.asciidoc | 2 +-
Documentation/btrfstune.asciidoc| 2 +-
btrfs-convert.c | 2
Hi,
I found these with lintian (analysis tool for Debian packages) this
evening, and hope this patch is well received :-) The only bit I'm
unsure about is the deletion of what looks like extra whitespace on
the last changed line of the patch.
Cheers,
Nicholas
Nicholas D Steeves (1):
Fix user-
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
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 a per-file
basis also loses checksum correctness of such file.
24.09.2016
On Sat, 2016-09-24 at 23:44 +0200, Adam Borowski wrote:
> This would require teaching btrfs that, in some cases, a csum
> mismatch is no
> big thing and it can legitimately return junk data (like most other
> filesystems) rather than complaining. Same for scrub and btrfs
> check.
Well, I see no po
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 09/23/2016 02:24 AM, Omar Sandoval wrote:
> From: Omar Sandoval
>
> There are two separate issues that can lead to corrupted free space
> trees.
>
> 1. The free space tree bitmaps had an endianness issue on big-endian
>systems which is fixed by an earlier patch in this series.
> 2. btrfs-
On Sat, 2016-09-24 at 12:43 +, Hugo Mills wrote:
> It's because you can't update the data and the checksum atomically
> -- at some point in the writing process, they must be inconsistent.
> This is considered a Bad Thing.
It's not worse at all than simply not cheksuming... in both cases you
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 more difficult, since the meta-data itself is
still subject to CoW...
There's
Thanks for the info. So this actually happened with the latest
official Ubuntu 16.04 kernel, 4.4.0-38-generic x86_64. I looked up the
commit you mentioned and it seems like it was included in 2015 so
should definitely be in the 4.4.0-38, which corresponds to the 4.4.19
mainline kernel afaik.
Mark
On Sat, Sep 24, 2016 at 05:40:12PM +0500, Roman Mamedov wrote:
> On Sat, 24 Sep 2016 15:26:14 +0300
> Alexander Tomokhov wrote:
>
> > does setting No_COW on a file (chattr +C) imply disabling data checksumming
> > on it?
>
> Yes. IIRC the reasoning was that it's more difficult to track checksum
On Sat, 24 Sep 2016 15:26:14 +0300
Alexander Tomokhov wrote:
> does setting No_COW on a file (chattr +C) imply disabling data checksumming
> on it?
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).
> may it
On Sat, Sep 24, 2016 at 03:26:14PM +0300, Alexander Tomokhov wrote:
> There is an unanswered question at stackexchange:
> http://unix.stackexchange.com/q/303130/41572
>
> Assume that we don't invoke mount options like nodatacow and nodatasum -
> operate only at file attributes level, which are co
There is an unanswered question at stackexchange:
http://unix.stackexchange.com/q/303130/41572
Assume that we don't invoke mount options like nodatacow and nodatasum -
operate only at file attributes level, which are controlled with lsattr/chattr.
So does setting No_COW on a file (chattr +C) imp
15 matches
Mail list logo
