Re: [PATCH 00/14 RFC] Btrfs: Add journal for raid5/6 writes

On 2017-08-03 06:02, Duncan wrote: > Liu Bo posted on Wed, 02 Aug 2017 14:27:21 -0600 as excerpted: > > It is correct reading this as: all data is written two times ? > > If as is being discussed the log is mirrored by default that'd be three > times... And for raid6 you need to do it 4

Re: [PATCH 00/14 RFC] Btrfs: Add journal for raid5/6 writes

Liu Bo posted on Wed, 02 Aug 2017 14:27:21 -0600 as excerpted: >> >> It is correct reading this as: all data is written two times ? If as is being discussed the log is mirrored by default that'd be three times... Parity-raid is slow and of course normally has the infamous write hole this

Re: Massive loss of disk space

Goffredo Baroncelli posted on Wed, 02 Aug 2017 19:52:30 +0200 as excerpted: > it seems that BTRFS always allocate the maximum space required, without > consider the one already allocated. Is it too conservative ? I think no: > consider the following scenario: > > a) create a 2GB file > b)

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

On Wed, Aug 2, 2017 at 2:38 AM, Brendan Hide wrote: > The title seems alarmist to me - and I suspect it is going to be > misconstrued. :-/ Josef pushed bak on the HN thread with very sound reasoning about why this is totally unsurprising. RHEL runs old kernels, and

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

On Thu, Aug 3, 2017 at 1:44 AM, Chris Mason wrote: > > On 08/02/2017 04:38 AM, Brendan Hide wrote: >> >> The title seems alarmist to me - and I suspect it is going to be >> misconstrued. :-/ > > > Supporting any filesystem is a huge amount of work. I don't have a problem > with

[PATCH] 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 --- fs/btrfs/raid56.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 00/14 RFC] Btrfs: Add journal for raid5/6 writes

On Wed, Aug 02, 2017 at 10:41:30PM +0200, Goffredo Baroncelli wrote: > Hi Liu, > > thanks for your reply, below my comments > On 2017-08-02 19:57, Liu Bo wrote: > > On Wed, Aug 02, 2017 at 12:14:27AM +0200, Goffredo Baroncelli wrote: > >> On 2017-08-01 19:24, Liu Bo wrote: > >>> On Tue, Aug 01,

Re: Massive loss of disk space

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 is that c) always succeed

Re: [PATCH 00/14 RFC] Btrfs: Add journal for raid5/6 writes

Hi Liu, thanks for your reply, below my comments On 2017-08-02 19:57, Liu Bo wrote: > On Wed, Aug 02, 2017 at 12:14:27AM +0200, Goffredo Baroncelli wrote: >> On 2017-08-01 19:24, Liu Bo wrote: >>> On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote: Hi Liu, On

[PATCH] btrfs: pass fs_info to routines that always take tree_root

From: Jeff Mahoney btrfs_find_root and btrfs_del_root always use the tree_root. Let's pass fs_info instead. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h | 7 --- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 4 ++--

Re: [PATCH 01/14] Btrfs: raid56: add raid56 log via add_dev v2 ioctl

On 1.08.2017 19:14, Liu Bo wrote: > This introduces add_dev_v2 ioctl to add a device as raid56 journal > device. With the help of a journal device, raid56 is able to to get > rid of potential write holes. > > Signed-off-by: Liu Bo > --- > fs/btrfs/ctree.h

Re: Massive loss of disk space

On 2017-08-02 13:52, Goffredo Baroncelli wrote: Hi, On 2017-08-01 17:00, Austin S. Hemmelgarn wrote: OK, I just did a dead simple test by hand, and it looks like I was right. The method I used to check this is as follows: 1. Create and mount a reasonably small filesystem (I used an 8G

Re: [PATCH 00/14 RFC] Btrfs: Add journal for raid5/6 writes

On Wed, Aug 02, 2017 at 12:14:27AM +0200, Goffredo Baroncelli wrote: > On 2017-08-01 19:24, Liu Bo wrote: > > On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote: > >> Hi Liu, > >> > >> On 2017-08-01 18:14, Liu Bo wrote: > >>> This aims to fix write hole issue on btrfs raid5/6

[PATCH 2/3] fixed android.mk

From: Filip Bystricky Signed-off-by: Filip Bystricky Reviewed-by: Mark Salyzyn --- Android.mk | 53 + 1 file changed, 21 insertions(+), 32 deletions(-) diff --git

[PATCH 3/3] compile error fixes

From: Filip Bystricky Android currently does not fully support libblkid, and android's bionic doesn't implement some pthread extras such as pthread_tryjoin_np and pthread_cancel. This patch fixes the resulting errors while trying to be as unobtrusive as possible,

[PATCH 1/3] copied android.mk from devel branch

From: Filip Bystricky This series of patches fixes some compile errors that trigger when compiling to android devices. This first patch just brings in devel's Android.mk, to which kdave@ added a few fixes recently. Signed-off-by: Filip Bystricky

Re: [PATCH 00/14 RFC] Btrfs: Add journal for raid5/6 writes

On 08/01/2017 01:39 PM, Austin S. Hemmelgarn wrote: On 2017-08-01 13:25, Roman Mamedov wrote: On Tue, 1 Aug 2017 10:14:23 -0600 Liu Bo wrote: This aims to fix write hole issue on btrfs raid5/6 setup by adding a separate disk as a journal (aka raid5/6 log), so that

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

On 08/02/2017 04:38 AM, Brendan Hide wrote: The title seems alarmist to me - and I suspect it is going to be misconstrued. :-/ Supporting any filesystem is a huge amount of work. I don't have a problem with Redhat or any distro picking and choosing the projects they want to support. At

Re: Massive loss of disk space

Hi, On 2017-08-01 17:00, Austin S. Hemmelgarn wrote: > OK, I just did a dead simple test by hand, and it looks like I was right. > The method I used to check this is as follows: > 1. Create and mount a reasonably small filesystem (I used an 8G temporary LV > for this, a file would work too

Re: [PATCH] btrfs: copy fsid to super_block s_uuid

On Wed, Aug 02, 2017 at 02:02:11PM +0800, Anand Jain wrote: > > Hi Darrick, > > Thanks for commenting.. > > >>+ memcpy(>s_uuid, fs_info->fsid, BTRFS_FSID_SIZE); > > > >uuid_copy()? > > It requires a larger migration to use uuid_t, IMO it can be done all > together, in a separate patch ?

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

On 2017-08-02 08:55, Lutz Vieweg wrote: On 08/02/2017 01:25 PM, Austin S. Hemmelgarn wrote: And this is a worst-case result of the fact that most distros added BTRFS support long before it was ready. RedHat still advertises "Ceph", and given Ceph initially recommended btrfs as the

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

On 08/02/2017 01:25 PM, Austin S. Hemmelgarn wrote: And this is a worst-case result of the fact that most distros added BTRFS support long before it was ready. RedHat still advertises "Ceph", and given Ceph initially recommended btrfs as the filesystem to use for its nodes, it is interesting

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

On 2017-08-02 04:38, 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-02 00:14, Duncan wrote: Austin S. Hemmelgarn posted on Tue, 01 Aug 2017 10:47:30 -0400 as excerpted: I think I _might_ understand what's going on here. Is that test program calling fallocate using the desired total size of the file, or just trying to allocate the range beyond the

Re: Crashed filesystem, nothing helps

With the help of btrfs-corrupt-block i was able to get a little bit farer. I marked some of my problem block corrupt. Now i am in this stage mainframe:~ # btrfs restore /dev/sdb1 /mnt parent transid verify failed on 29409280 wanted 1486829 found 1488801 parent transid verify failed on 29409280

Re: Crashed filesystem, nothing helps

Am Mittwoch, 2. August 2017, 11:31:41 CEST schrieb Roman Mamedov: > Did it just abruptly exit there? Or you terminated it? It apruptly stopped there Regards, Thomas -- Thomas Wurfbaum Starkertshofen 15 85084 Reichertshofen Tel.: +49-160-3696336 Mail: tho...@wurfbaum.net

Re: Crashed filesystem, nothing helps

On Wed, 02 Aug 2017 11:17:04 +0200 Thomas Wurfbaum wrote: > A restore does also not help: > mainframe:~ # btrfs restore /dev/sdb1 /mnt > parent transid verify failed on 29392896 wanted 1486833 found 1486836 > parent transid verify failed on 29392896 wanted 1486833 found

Re: Crashed filesystem, nothing helps

Maybe you are right, but i just followed the Suse guide: https://en.opensuse.org/SDB:BTRFS How to repair a broken/unmountable btrfs filesystem I already tried the commands mount with the -o usebackuproot option. (And -o usebackuproot,ro as well) But they just produce this in dmesg:

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

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! On Wed, Aug 2, 2017 at 4:38 PM, Brendan Hide wrote: > The title seems alarmist to me - and I suspect it is going to be >

Re: Crashed filesystem, nothing helps

On Wed, Aug 02, 2017 at 10:27:50AM +0200, Thomas Wurfbaum wrote: > Hello, > > Yesterday morning i recognized a hard reboot of my system, but the /data > filesystem was > not possible to mount. > > > mainframe:~ # uname -a > Linux mainframe 4.11.8-2-default #1 SMP PREEMPT Thu Jun 29 14:37:33

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

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_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html "Btrfs

[no subject]

subscribe linux-btrfs -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: BTRFS error: bad tree block start 0 623771648

Thanks you for the information. It looks indeed like there are some important parts all zerod... I will try to hijack to code to get easy access to some config directories. I already reinstalled the Operating System, now with dup Metadata and will have a deeper look at the discard flag. The

Re: Crashed filesystem, nothing helps

Please find attached my dmesg.log Regards, Thomas[0.00] Linux version 4.11.8-2-default (geeko@buildhost) (gcc version 7.1.1 20170629 [gcc-7-branch revision 249772] (SUSE Linux) ) #1 SMP PREEMPT Thu Jun 29 14:37:33 UTC 2017 (42bd7a0) [0.00] Command line:

Crashed filesystem, nothing helps

Hello, Yesterday morning i recognized a hard reboot of my system, but the /data filesystem was not possible to mount. mainframe:~ # uname -a Linux mainframe 4.11.8-2-default #1 SMP PREEMPT Thu Jun 29 14:37:33 UTC 2017 (42bd7a0) x86_64 x86_64 x86_64 GNU/Linux mainframe:~ # btrfs --version

Re: [PATCH 0/2] More nritems range checking

Hello, Am 02.06.2017 um 12:08 schrieb Philipp Hahn: > thank you for applying my last patch, but regarding my corrputed file system I > found two other cases were btrfs crashes: > - btrfs_del_items() was overlooked by me > - deleting from an empty node > > Find attached two patches to improve

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

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 (due to lack of space, for example) and the file had no acl attribute to begin

Re: [PATCH] btrfs: verify_dir_item fails in replay_xattr_deletes

On 2.08.2017 08:35, Lu Fengqi wrote: > From: Su Yue > > In replay_xattr_deletes(), the argument @slot of verify_dir_item() > should be variable @i instead of path->slots[0]. This was already fix in a patch sent by Filipe. Title is: [PATCH] Btrfs: fix dir item