[PATCH] btrfs-progs: Fix cross-compile error for mktables

When cross compiling btrfs-progs, following error will prevent btrfs-progs to be compiled: [CC] mktables [TABLE] kernel-lib/tables.c /bin/sh: ./mktables: cannot execute binary file: Exec format error make: *** No rule to make target 'kernel-lib/tables.c', needed by

[RESEND PATCH] btrfs-progs: Specify C standard to gnu90 explicitly

Different C compilers have different default language standard. This sometimes causes problem on different system. For distribution like CentOS/RHEL7, its gcc is still 4.8 and will report error for c90 style declaration, while most developers are using newer gcc which will just ignore it. This

Re: btrfs fi du -s gives Inappropriate ioctl for device

On Mon, Aug 14, 2017 at 4:57 PM, Piotr Szymaniak wrote: > > and... some issues: > ~ # btrfs fi du -s /mnt/red/\@backup/ > Total Exclusive Set shared Filename > ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for > device It's a bug, but I

Re: btrfs-progs-v4.12: cross compiling

On 2017年08月15日 02:57, Goffredo Baroncelli wrote: On 08/14/2017 05:10 PM, David Sterba wrote: On Mon, Aug 14, 2017 at 10:14:42PM +0800, Qu Wenruo wrote: [...] mktables.c is synced from kernel sources, taking updates from there is easier than porting any changes to the proposed scripted

btrfs fi du -s gives Inappropriate ioctl for device

Hi list, I have some weird issue. So, I have btrfs fs and some subvols, like that: ~ # btrfs sub list /mnt/red/ ID 260 gen 827956 top level 5 path @home ID 261 gen 827926 top level 5 path @backup ID 645 gen 827911 top level 5 path @svn *snip* and some snapshots on those subvols: *snip* ID 2501

Re: [RFC] Checksum of the parity

On Mon, Aug 14, 2017 at 2:18 PM, Goffredo Baroncelli wrote: >> Anyway, I do wish I read the code better, so I knew exactly where, if >> at all, the RMW code was happening on disk rather than just in memory. >> There very clearly is RMW in memory code as a performanc

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 08/14/2017 09:08 PM, Chris Murphy wrote: > On Mon, Aug 14, 2017 at 8:23 AM, Goffredo Baroncelli > wrote: > >> Form a theoretical point of view, if you have a "PURE" COW file-system, you >> don't need a journal. Unfortunately a RAID5/6 stripe update is a RMW cycle, >> so

Re: [RFC] Checksum of the parity

On 08/14/2017 09:28 PM, Chris Murphy wrote: > On Mon, Aug 14, 2017 at 8:12 AM, Goffredo Baroncelli > wrote: >> On 08/13/2017 08:45 PM, Chris Murphy wrote: >>> [2] >>> Is Btrfs subject to the write hole problem manifesting on disk? I'm >>> not sure, sadly I don't read the code

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Mon, 2017-08-14 at 11:53 -0400, Austin S. Hemmelgarn wrote: > Quite a few applications actually _do_ have some degree of secondary  > verification or protection from a crash.  Go look at almost any > database  > software. Then please give proper references for this! This is from 2015, where

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Mon, 2017-08-14 at 10:23 -0400, Austin S. Hemmelgarn wrote: > Assume you have higher level verification.  Would you rather not be > able  > to read the data regardless of if it's correct or not, or be able to  > read it and determine yourself if it's correct or not? What would be the

Re: [RFC] Checksum of the parity

On Mon, Aug 14, 2017 at 8:12 AM, Goffredo Baroncelli wrote: > On 08/13/2017 08:45 PM, Chris Murphy wrote: >> [2] >> Is Btrfs subject to the write hole problem manifesting on disk? I'm >> not sure, sadly I don't read the code well enough. But if all Btrfs >> raid56 writes are

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Mon, Aug 14, 2017 at 8:23 AM, Goffredo Baroncelli wrote: > Form a theoretical point of view, if you have a "PURE" COW file-system, you > don't need a journal. Unfortunately a RAID5/6 stripe update is a RMW cycle, > so you need a journal to keep it in sync. The same is

Re: btrfs-progs-v4.12: cross compiling

On 08/14/2017 05:10 PM, David Sterba wrote: > On Mon, Aug 14, 2017 at 10:14:42PM +0800, Qu Wenruo wrote: [...] > mktables.c is synced from kernel sources, taking updates from there is > easier than porting any changes to the proposed scripted implementation. > > The workflow is simple: > - copy

[PATCH] btrfs: test incremental send with compression and extent cloning

From: Filipe Manana Test that an incremental send/receive operation will not fail when the destination filesystem has compression enabled and the source filesystem has a 4K extent at a file offset 0 that is not compressed and that is shared. This currently fails on btrfs and

[PATCH] Btrfs: incremental send, fix emission of invalid clone operations

From: Filipe Manana When doing an incremental send it's possible that the computed send stream contains clone operations that will fail on the receiver if the receiver has compression enabled and the clone operations target a sector sized extent that starts at a zero file

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 14/08/17 16:53, Austin S. Hemmelgarn wrote: > Quite a few applications actually _do_ have some degree of secondary > verification or protection from a crash. I am glad your applications do and you have no need of this feature. You are welcome not to use it. I, on the other hand, definitely

Re: [PATCH v3] btrfs: preserve i_mode if __btrfs_set_acl() fails

On Wed, Aug 02, 2017 at 03:18:27AM -0300, Ernesto A. Fernández wrote: > When changing a file's acl mask, btrfs_set_acl() will first set the > group bits of i_mode to the value of the mask, and only then set the > actual extended attribute representing the new acl. > > If the second part fails

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017-08-14 11:13, Graham Cobb wrote: On 14/08/17 15:23, Austin S. Hemmelgarn wrote: Assume you have higher level verification. But almost no applications do. In real life, the decision making/correction process will be manual and labour-intensive (for example, running fsck on a virtual

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 14/08/17 15:23, Austin S. Hemmelgarn wrote: > Assume you have higher level verification. But almost no applications do. In real life, the decision making/correction process will be manual and labour-intensive (for example, running fsck on a virtual disk or restoring a file from backup). >

Re: btrfs-progs-v4.12: cross compiling

On Mon, Aug 14, 2017 at 10:14:42PM +0800, Qu Wenruo wrote: > On 2017年08月14日 22:03, David Sterba wrote: > > On Mon, Aug 14, 2017 at 09:17:08PM +0800, Qu Wenruo wrote: > >> On 2017年08月14日 21:06, David Sterba wrote: > >>> On Mon, Aug 14, 2017 at 02:17:26PM +0200, Hallo32 wrote: > Since versions

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017-08-14 08:24, Christoph Anton Mitterer wrote: On Mon, 2017-08-14 at 14:36 +0800, Qu Wenruo wrote: And how are you going to write your data and checksum atomically when doing in-place updates? Exactly, that's the main reason I can figure out why btrfs disables checksum for nodatacow.

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 08/14/2017 09:08 AM, Qu Wenruo wrote: > >> >> Supposing to log for each transaction BTRFS which "data NOCOW blocks" will >> be updated and their checksum, in case a transaction is interrupted you know >> which blocks have to be checked and are able to verify if the checksum >> matches and

Re: btrfs-progs-v4.12: cross compiling

On 2017年08月14日 22:03, David Sterba wrote: On Mon, Aug 14, 2017 at 09:17:08PM +0800, Qu Wenruo wrote: On 2017年08月14日 21:06, David Sterba wrote: On Mon, Aug 14, 2017 at 02:17:26PM +0200, Hallo32 wrote: Since versions 4.12 btrfs-progs is complicated to cross compile for other systems. The

Re: [RFC] Checksum of the parity

On 08/13/2017 08:45 PM, Chris Murphy wrote: > [2] > Is Btrfs subject to the write hole problem manifesting on disk? I'm > not sure, sadly I don't read the code well enough. But if all Btrfs > raid56 writes are full stripe CoW writes, and if the prescribed order > guarantees still happen: data CoW

Re: btrfs-progs-v4.12: cross compiling

On Mon, Aug 14, 2017 at 09:17:08PM +0800, Qu Wenruo wrote: > > > On 2017年08月14日 21:06, David Sterba wrote: > > On Mon, Aug 14, 2017 at 02:17:26PM +0200, Hallo32 wrote: > >> Since versions 4.12 btrfs-progs is complicated to cross compile for > >> other systems. > >> The problem is, that this

Re: Building a BTRFS test machine

On 2017-08-13 21:01, Cerem Cem ASLAN wrote: Would that be useful to build a BTRFS test machine, which will perform both software tests (btrfs send | btrfs receive, read/write random data etc.) and hardware tests, such as abrupt power off test, abruptly removing a raid-X disk physically, etc. In

Re: [PATCH v5 2/5] lib: Add zstd modules

On Fri, Aug 11, 2017 at 09:20:10AM -0400, Chris Mason wrote: > > > On 08/10/2017 03:25 PM, Hugo Mills wrote: > > On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: > >> On 08/10/2017 04:30 AM, Eric Biggers wrote: > >>> > >>> Theses benchmarks are misleading because they compress the

Re: lazytime mount option—no support in Btrfs

On 2017-08-13 07:50, Adam Hunt wrote: Back in 2014 Ted Tso introduced the lazytime mount option for ext4 and shortly thereafter a more generic VFS implementation which was then merged into mainline. His early patches included support for Btrfs but those changes were removed prior to the feature

Re: btrfs-progs-v4.12: cross compiling

On 2017年08月14日 21:06, David Sterba wrote: On Mon, Aug 14, 2017 at 02:17:26PM +0200, Hallo32 wrote: Since versions 4.12 btrfs-progs is complicated to cross compile for other systems. The problem is, that this version includes mktables, which needs to be compiled for the host system and

Re: btrfs-progs-v4.12: cross compiling

On 2017年08月14日 20:17, Hallo32 wrote: Hello at all, I'm new at this list. If the mail is not in line with your standards please inform me. Since versions 4.12 btrfs-progs is complicated to cross compile for other systems. The problem is, that this version includes mktables, which needs to

Re: btrfs-progs-v4.12: cross compiling

On Mon, Aug 14, 2017 at 02:17:26PM +0200, Hallo32 wrote: > Since versions 4.12 btrfs-progs is complicated to cross compile for > other systems. > The problem is, that this version includes mktables, which needs to be > compiled for the host system and executed there for the creation of >

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017年08月14日 20:32, Christoph Anton Mitterer wrote: On Mon, 2017-08-14 at 15:46 +0800, Qu Wenruo wrote: The problem here is, if you enable csum and even data is updated correctly, only metadata is trashed, then you can't even read out the correct data. So what? This problem occurs anyway

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Mon, 2017-08-14 at 15:46 +0800, Qu Wenruo wrote: > The problem here is, if you enable csum and even data is updated  > correctly, only metadata is trashed, then you can't even read out > the  > correct data. So what? This problem occurs anyway *only* in case of a crash,.. and *only* if

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Mon, 2017-08-14 at 14:36 +0800, Qu Wenruo wrote: > > And how are you going to write your data and checksum atomically > > when > > doing in-place updates? > > Exactly, that's the main reason I can figure out why btrfs disables  > checksum for nodatacow. Still, I don't get the problem here...

btrfs-progs-v4.12: cross compiling

Hello at all, I'm new at this list. If the mail is not in line with your standards please inform me. Since versions 4.12 btrfs-progs is complicated to cross compile for other systems. The problem is, that this version includes mktables, which needs to be compiled for the host system and

Re: how to benchmark schedulers

On 2017年08月08日 21:19, Janos Toth F. wrote: I think you should consider using Linux 4.12 which has bfq (bfq-mq) for blk-mq. So, you don't need out-of-tree BFQ patches if you switch to blk-mq (but now you are free to do so even if you have HDDs or SSDs which benefit from software schedulers

Re: Building a BTRFS test machine

Definitely it will be useful. For quite sometime, I was thinking about: 1. Creating test cases for each BTRFS features. (ex: https://btrfs.wiki.kernel.org/index.php/Scrub_corruption_cases) 2. Automate these feature specific test scripts using bash/python while maintaining them in public git

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017年08月14日 15:43, Paul Jones wrote: -Original Message- From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- ow...@vger.kernel.org] On Behalf Of Qu Wenruo Sent: Monday, 14 August 2017 4:37 PM To: Christoph Hellwig ; Christoph Anton Mitterer

RE: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- > ow...@vger.kernel.org] On Behalf Of Qu Wenruo > Sent: Monday, 14 August 2017 4:37 PM > To: Christoph Hellwig ; Christoph Anton Mitterer > > Cc: Btrfs BTRFS

Re: Building a BTRFS test machine

On 2017年08月14日 09:01, Cerem Cem ASLAN wrote: Would that be useful to build a BTRFS test machine, which will perform both software tests (btrfs send | btrfs receive, read/write random data etc.) and hardware tests, such as abrupt power off test, abruptly removing a raid-X disk physically, etc.

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017年08月13日 22:08, Goffredo Baroncelli wrote: On 08/12/2017 02:12 PM, Hugo Mills wrote: On Sat, Aug 12, 2017 at 01:51:46PM +0200, Christoph Anton Mitterer wrote: On Sat, 2017-08-12 at 00:42 -0700, Christoph Hellwig wrote: [...] good, but csum is not I don't think

Re: [PATCH] btrfs: use BTRFS_FSID_SIZE for fsid

On 13.08.2017 06:58, Anand Jain wrote: > We have define for FSID size so use it. > > Signed-off-by: Anand Jain I like consistency! Reviewed-by: Nikolay Borisov -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of

[PATCH] fstests: btrfs: enhance regression test for nocsum dio read's repair

I catch this following error from dmesg when this testcase fails. [17446.661127] Buffer I/O error on dev sdb1, logical block 64, async page read We expect to inject disk IO errors on the device when xfs_io reads the specific file, but other processes may trigger IO error earlier. So, we can use

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 2017年08月12日 15:42, Christoph Hellwig wrote: On Sat, Aug 12, 2017 at 02:10:18AM +0200, Christoph Anton Mitterer wrote: Qu Wenruo wrote: Although Btrfs can disable data CoW, nodatacow also disables data checksum, which is another main feature for btrfs. Then decoupling of the two should