Re: Status of RAID5/6

On Wed, Apr 04, 2018 at 11:31:33PM +0200, Goffredo Baroncelli wrote: > On 04/04/2018 08:01 AM, Zygo Blaxell wrote: > > On Wed, Apr 04, 2018 at 07:15:54AM +0200, Goffredo Baroncelli wrote: > >> On 04/04/2018 12:57 AM, Zygo Blaxell wrote: > [...] > >> Before you pointed out that the non-contiguous

Re: Status of RAID5/6

On 04/04/2018 08:01 AM, Zygo Blaxell wrote: > On Wed, Apr 04, 2018 at 07:15:54AM +0200, Goffredo Baroncelli wrote: >> On 04/04/2018 12:57 AM, Zygo Blaxell wrote: [...] >> Before you pointed out that the non-contiguous block written has >> an impact on performance. I am replaying that the

[PATCH] btrfs-progs: build: Do not use cp -a to install files

Using cp -a to install files will preserve the ownership of the original files (if possible), which is typically not wanted. E.g., if the files were built by a normal user, but are being installed by root, then the installed files would maintain the UIDs/GIDs of the user that built the files

[PATCH] btrfs: Drop delayed_refs argument from btrfs_check_delayed_seq

It's used to print its pointer in a debug statement but doesn't really bring any useful information to the error message. Signed-off-by: Nikolay Borisov --- fs/btrfs/delayed-ref.c | 9 +++-- fs/btrfs/delayed-ref.h | 4 +--- fs/btrfs/extent-tree.c | 2 +- 3 files changed,

Re: Status of RAID5/6

On Tue, Apr 03, 2018 at 09:08:01PM -0600, Chris Murphy wrote: > On Tue, Apr 3, 2018 at 11:03 AM, Goffredo Baroncelli > wrote: > > On 04/03/2018 02:31 AM, Zygo Blaxell wrote: > >> On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: > >>> On Mon, Apr 02, 2018 at

[PATCH RESEND 1/2] btrfs: Enhance btrfs_trim_fs function to handle error better

Function btrfs_trim_fs() doesn't handle errors in a consistent way, if error happens when trimming existing block groups, it will skip the remaining blocks and continue to trim unallocated space for each device. And the return value will only reflect the final error from device trimming. This

[PATCH RESEND 2/2] btrfs: Ensure btrfs_trim_fs can trim the whole fs

[BUG] fstrim on some btrfs only trims the unallocated space, not trimming any space in existing block groups. [CAUSE] Before fstrim_range passed to btrfs_trim_fs(), it get truncated to range [0, super->total_bytes). So later btrfs_trim_fs() will only be able to trim block groups in range [0,

Re: Status of RAID5/6

On Wed, Apr 04, 2018 at 07:15:54AM +0200, Goffredo Baroncelli wrote: > On 04/04/2018 12:57 AM, Zygo Blaxell wrote: > >> I have to point out that in any case the extent is physically > >> interrupted at the disk-stripe size. Assuming disk-stripe=64KB, if > >> you want to write 128KB, the first half