Power down tests...

Hi all, We're running a couple of experiments on our servers with btrfs (kernel version 4.4). And we're running some abrupt power-off tests for a couple of scenarios: 1. We have a filesystem on top of two different btrfs filesystems (distributed across N disks). i.e. Our filesystem lays out data

Re: Massive loss of disk space

In 30 seconds I should be able to fill about 200MB * 30 = 6GB. Requiring the parity to not grow larger than there is a 6GB additional space is possible to live with on a 10TB disk. It seems that for SnapRAID to have any chance to work correctly with parity on a BTRFS partition, it would need

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

On Thu, Aug 3, 2017 at 2:45 PM, Brendan Hide wrote: > > To counter, I think this is a big problem with btrfs, especially in terms of > user attrition. We don't need "GUI" tools. At all. But we do need that btrfs > is self-sufficient enough that regular users don't get

[PATCH v2] Btrfs: search parity device wisely

After mapping block with BTRFS_MAP_WRITE, parities have been sorted to the end position, so this search can start from the first parity stripe. Signed-off-by: Liu Bo --- v2: fix typo (data_stripes -> nr_data). fs/btrfs/raid56.c | 3 ++- 1 file changed, 2 insertions(+), 1

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

On 08/03/2017 09:22 PM, Austin S. Hemmelgarn wrote: On 2017-08-03 14:29, Christoph Anton Mitterer wrote: On Thu, 2017-08-03 at 20:08 +0200, waxhead wrote: There are no higher-level management tools (e.g. RAID management/monitoring, etc.)... [snip] As far as 'higher-level' management tools,

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

On 2017-08-03 14:29, Christoph Anton Mitterer wrote: On Thu, 2017-08-03 at 20:08 +0200, waxhead wrote: Brendan Hide wrote: The title seems alarmist to me - and I suspect it is going to be misconstrued. :-/ From the release notes at

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

On Wed, Aug 2, 2017 at 3:11 AM, Wang Shilong wrote: > I haven't seen active btrfs developers from some time, Redhat looks > put most of their efforts on XFS, It is time to switch to SLES/opensuse! I disagree. We need one or more Btrfs developers involved in Fedora.

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

On 2017-08-03 14:08, waxhead wrote: Brendan Hide wrote: The title seems alarmist to me - and I suspect it is going to be misconstrued. :-/ From the release notes at

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

On Thu, 2017-08-03 at 20:08 +0200, waxhead wrote: > Brendan Hide wrote: > > The title seems alarmist to me - and I suspect it is going to be  > > misconstrued. :-/ > > > > From the release notes at  > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Li > >

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

Brendan Hide wrote: The title seems alarmist to me - and I suspect it is going to be misconstrued. :-/ From the release notes at

Re: Massive loss of disk space

On 2017-08-03 13:15, Marat Khalili wrote: On August 3, 2017 7:01:06 PM GMT+03:00, Goffredo Baroncelli The file is physically extended ghigo@venice:/tmp$ fallocate -l 1000 foo.txt For clarity let's replace the fallocate above with: $ head -c 1000 foo.txt ghigo@venice:/tmp$ ls -l foo.txt

Re: Massive loss of disk space

On 2017-08-03 12:37, Goffredo Baroncelli wrote: On 2017-08-03 13:39, Austin S. Hemmelgarn wrote: On 2017-08-02 17:05, Goffredo Baroncelli wrote: On 2017-08-02 21:10, Austin S. Hemmelgarn wrote: On 2017-08-02 13:52, Goffredo Baroncelli wrote: Hi, [...] consider the following scenario: a)

Re: Massive loss of disk space

On August 3, 2017 7:01:06 PM GMT+03:00, Goffredo Baroncelli >The file is physically extended > >ghigo@venice:/tmp$ fallocate -l 1000 foo.txt For clarity let's replace the fallocate above with: $ head -c 1000 foo.txt >ghigo@venice:/tmp$ ls -l foo.txt >-rw-r--r-- 1 ghigo ghigo 1000 Aug 3 18:00

Re: Massive loss of disk space

On 2017-08-03 13:39, Austin S. Hemmelgarn wrote: > On 2017-08-02 17:05, Goffredo Baroncelli wrote: >> On 2017-08-02 21:10, Austin S. Hemmelgarn wrote: >>> On 2017-08-02 13:52, Goffredo Baroncelli wrote: Hi, >> [...] >> consider the following scenario: a) create a 2GB file

Re: Massive loss of disk space

On 2017-08-03 13:44, Marat Khalili wrote: > On 02/08/17 20:52, Goffredo Baroncelli wrote: >> consider the following scenario: >> >> a) create a 2GB file >> b) fallocate -o 1GB -l 2GB >> c) write from 1GB to 3GB >> >> after b), the expectation is that c) always succeed [1]: i.e. there is >> enough

Re: [PATCH] Btrfs: avoid unnecessarily locking inode when clearing a range

On 08/03/2017 11:25 AM, Wang Shilong wrote: On Thu, Aug 3, 2017 at 11:00 PM, Chris Mason wrote: On 07/27/2017 02:52 PM, fdman...@kernel.org wrote: From: Filipe Manana If the range being cleared was not marked for defrag and we are not about to clear the

Re: [PATCH] Btrfs: avoid unnecessarily locking inode when clearing a range

On Thu, Aug 3, 2017 at 11:00 PM, Chris Mason wrote: > > > On 07/27/2017 02:52 PM, fdman...@kernel.org wrote: >> >> From: Filipe Manana >> >> If the range being cleared was not marked for defrag and we are not >> about to clear the range from the defrag status, we

Re: [PATCH] btrfs: Move skip checksum check from btrfs_submit_direct to __btrfs_submit_dio_bio

On 08/03/2017 08:44 AM, Nikolay Borisov wrote: Currently the code checks whether we should do data checksumming in btrfs_submit_direct and the boolean result of this check is passed to btrfs_submit_direct_hook, in turn passing it to __btrfs_submit_dio_bio which actually consumes it. The last

Re: [PATCH] Btrfs: avoid unnecessarily locking inode when clearing a range

On 07/27/2017 02:52 PM, fdman...@kernel.org wrote: From: Filipe Manana If the range being cleared was not marked for defrag and we are not about to clear the range from the defrag status, we don't need to lock and unlock the inode. Signed-off-by: Filipe Manana

[PATCH] btrfs: Move skip checksum check from btrfs_submit_direct to __btrfs_submit_dio_bio

Currently the code checks whether we should do data checksumming in btrfs_submit_direct and the boolean result of this check is passed to btrfs_submit_direct_hook, in turn passing it to __btrfs_submit_dio_bio which actually consumes it. The last function actually has all the necessary context to

Re: [PATCH] Btrfs: search parity device wisely

Hi Liu, [auto build test ERROR on v4.13-rc3] [also build test ERROR on next-20170803] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Liu-Bo/Btrfs-search-parity-device-wisely/20170803-193103

Re: [PATCH] Btrfs: search parity device wisely

Hi Liu, [auto build test ERROR on v4.13-rc3] [also build test ERROR on next-20170803] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Liu-Bo/Btrfs-search-parity-device-wisely/20170803-193103

Re: Massive loss of disk space

On 2017-08-03 07:44, Marat Khalili wrote: On 02/08/17 20:52, Goffredo Baroncelli wrote: consider the following scenario: a) create a 2GB file b) fallocate -o 1GB -l 2GB c) write from 1GB to 3GB after b), the expectation is that c) always succeed [1]: i.e. there is enough space on the

Re: Massive loss of disk space

On 02/08/17 20:52, Goffredo Baroncelli wrote: consider the following scenario: a) create a 2GB file b) fallocate -o 1GB -l 2GB c) write from 1GB to 3GB after b), the expectation is that c) always succeed [1]: i.e. there is enough space on the filesystem. Due to the COW nature of BTRFS, you

Re: Massive loss of disk space

On 2017-08-02 17:05, Goffredo Baroncelli wrote: On 2017-08-02 21:10, Austin S. Hemmelgarn wrote: On 2017-08-02 13:52, Goffredo Baroncelli wrote: Hi, [...] consider the following scenario: a) create a 2GB file b) fallocate -o 1GB -l 2GB c) write from 1GB to 3GB after b), the expectation

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

On 08/03/2017 12:22 AM, Chris Murphy wrote: Also more interesting is this Stratis project that started up a few months ago: https://github.com/stratis-storage/stratisd Which also includes this design document: https://stratis-storage.github.io/StratisSoftwareDesign.pdf This concept, if