Re: Is it safe to use btrfs on top of different types of devices?

Zoltán Ivánfi posted on Sat, 14 Oct 2017 21:00:26 +0200 as excerpted: > Dear Btrfs Experts, > > A few years ago I tried to use a RAID1 mdadm array of a SATA and a USB > disk, which lead to strange error messages and data corruption. I did > some searching back then and found out that using hot-pl

Why isnt NOCOW attributes propogated on snapshot transfers?

`btrfs send | btrfs receive` removes NOCOW attributes. Is it a bug or a feature? If it's a feature, how can we keep these attributes if we need to? -- 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

Re: Is it safe to use btrfs on top of different types of devices?

> A few years ago I tried to use a RAID1 mdadm array of a SATA > and a USB disk, which lead to strange error messages and data > corruption. That's common, quite a few reports of similar issues in previous entries in this mailing list and for many other filesystems. > I did some searching back th

Re: [PATCH v2] btrfs-progs: allow "none" to disable compression for convenience

At Tue, 19 Sep 2017 17:14:27 +0200, David Sterba wrote: > > On Mon, Sep 18, 2017 at 09:41:17AM +0900, Satoru Takeuchi wrote: > > At Sun, 17 Sep 2017 14:08:40 +0100, > > Mike Fleetwood wrote: > > > > > > On 17 September 2017 at 01:36, Satoru Takeuchi > > > wrote: > > > > It's messy to use "" to d

Re: [PATCH RESEND] btrfs-progs: allow "no" to disable compression for convenience

At Sat, 14 Oct 2017 18:19:14 +0200, Koen Kooi wrote: > > Op 14-10-17 om 14:54 schreef Satoru Takeuchi: > > It's messy to use "" to disable compression. Introduce the new value "no" > > which can also be used for this purpose. > > Wouldn't 'none' be a better fit? I consider "no" is better because

Is it safe to use btrfs on top of different types of devices?

Dear Btrfs Experts, A few years ago I tried to use a RAID1 mdadm array of a SATA and a USB disk, which lead to strange error messages and data corruption. I did some searching back then and found out that using hot-pluggable devices with mdadm is a paved road to data corruption. Reading through th

Re: [PATCH] btrfs-progs: subvol list: don't print deleted subvol as TOPLEVEL

On Fri, Oct 13, 2017 at 05:17:22PM +0800, Lu Fengqi wrote: > We should use entry->root_id instead of top_id to determine whether it is > the toplevel subvolume. > > Signed-off-by: Lu Fengqi Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of

Re: [PATCH 00/21] My current btrfs patch queue

On Fri, Sep 29, 2017 at 03:43:44PM -0400, Josef Bacik wrote: > This is my current set of outstanding patches. A lot of these had reviews and > I've incorporated the feedback. They have been pretty thorougly tested and > are > pretty solid. > > [PATCH 01/21] Btrfs: rework outstanding_extents > [

Re: [PATCH 21/21] btrfs: add assertions for releasing trans handle reservations

On Fri, Sep 29, 2017 at 03:44:05PM -0400, Josef Bacik wrote: > These are useful for debugging problems where we mess with > trans->block_rsv to make sure we're not screwing something up. > > Signed-off-by: Josef Bacik Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "un

Re: [PATCH 07/21] Btrfs: only check delayed ref usage in should_end_transaction

On Fri, Sep 29, 2017 at 03:43:51PM -0400, Josef Bacik wrote: > We were only doing btrfs_check_space_for_delayed_refs() if the metadata > space was full, ie we couldn't allocate chunks. This assumes we'll be > able to allocate chunks during transaction commit, but since nothing > does a LIMIT flush

Re: [PATCH 15/21] btrfs: switch args for comp_*_refs

On Fri, Sep 29, 2017 at 03:43:59PM -0400, Josef Bacik wrote: > Because seriously? ref2 and then ref1? Brought to you by The infamous commit 5d4f98a28c7d334091c1b with diffstat 20 files changed, 6958 insertions(+), 2073 deletions(-) . But we still need some description of the impact of the chang

Re: [PATCH 19/21] btrfs: don't call btrfs_start_delalloc_roots in flushoncommit

On Fri, Sep 29, 2017 at 03:44:03PM -0400, Josef Bacik wrote: > We're holding the sb_start_intwrite lock at this point, and doing async > filemap_flush of the inodes will result in a deadlock if we freeze the > fs during this operation. This is because we could do a > btrfs_join_transaction() in th

Re: [PATCH] btrfs: set include path relatively

On Fri, Oct 13, 2017 at 04:01:31PM +0900, Naohiro Aota wrote: > 2017-10-12 21:38 GMT+09:00 David Sterba : > > On Thu, Oct 12, 2017 at 11:22:24AM +0900, Naohiro Aota wrote: > >> Currently, gcc is passed the include directory with full path. As a result, > >> dependency files (*.o.d) also record the

Re: [PATCH RESEND] btrfs-progs: allow "no" to disable compression for convenience

Op 14-10-17 om 14:54 schreef Satoru Takeuchi: > It's messy to use "" to disable compression. Introduce the new value "no" > which can also be used for this purpose. Wouldn't 'none' be a better fit? regards, Koen -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the bo

Re: [PATCH] btrfs: use BLK_STS defines where needed

At Sat, 14 Oct 2017 08:35:56 +0800, Anand Jain wrote: > > At few places we could use BLK_STS_OK and BLK_STS_NOSUPP. > > Signed-off-by: Anand Jain Reviewed-by: Satoru Taekeuchi > --- > fs/btrfs/compression.c | 3 ++- > fs/btrfs/inode.c | 4 ++-- > fs/btrfs/volumes.c | 2 +- > 3 file

[PATCH RESEND] btrfs-progs: allow "no" to disable compression for convenience

It's messy to use "" to disable compression. Introduce the new value "no" which can also be used for this purpose. Signed-off-by: Satoru Takeuchi --- Documentation/btrfs-property.asciidoc | 2 +- props.c | 6 -- 2 files changed, 5 insertions(+), 3 deletions(-)