Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > Unbreaks ARM and possibly other 32-bit architectures. Turns out those "other 32-bit architectures" happen to include i386. A modular build: ERROR: "__udivdi3" [fs/btrfs/btrfs.ko] undefined! With the patch, i386 builds fine. >

Re: About free space fragmentation, metadata write amplification and (no)ssd

Am Sun, 9 Apr 2017 02:21:19 +0200 schrieb Hans van Kranenburg : > On 04/08/2017 11:55 PM, Peter Grandi wrote: > >> [ ... ] This post is way too long [ ... ] > > > > Many thanks for your report, it is really useful, especially the > > details. > > Thanks! > >

Re: About free space fragmentation, metadata write amplification and (no)ssd

On 04/09/2017 02:21 AM, Hans van Kranenburg wrote: > [...] > Notice that everyone who has rotational 0 in /sys is experiencing this > behaviour right now, when removing snapshots... [...] Eh, 1 -- Hans van Kranenburg -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in

Re: About free space fragmentation, metadata write amplification and (no)ssd

On 04/08/2017 11:55 PM, Peter Grandi wrote: >> [ ... ] This post is way too long [ ... ] > > Many thanks for your report, it is really useful, especially the > details. Thanks! >> [ ... ] using rsync with --link-dest to btrfs while still >> using rsync, but with btrfs subvolumes and snapshots

[PATCH] btrfs-progs: Fix missing newline in man 5 btrfs

The text compress_lzo:: would show up directly after 'bigger than the page size' on the same line. --- Documentation/btrfs-man5.asciidoc | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc index c8ef1c96..90f16057 100644 ---

Re: About free space fragmentation, metadata write amplification and (no)ssd

> [ ... ] This post is way too long [ ... ] Many thanks for your report, it is really useful, especially the details. > [ ... ] using rsync with --link-dest to btrfs while still > using rsync, but with btrfs subvolumes and snapshots [1]. [ > ... ] Currently there's ~35TiB of data present on the

[PATCH] btrfs: scrub: use do_div() for 64-by-32 division

Unbreaks ARM and possibly other 32-bit architectures. Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len Reported-by: Icenowy Zheng Signed-off-by: Adam Borowski --- You'd probably want to squash this with Liu's commit, to be nice to future

Re: Does btrfs get nlink on directories wrong? -- was Re: [PATCH 2/4] xfstests: Add first statx test [ver #5]

Eryu Guan wrote: > > Overlayfs uses nlink = 1 for merge dirs to silence 'find' et al. > > Ext4 uses nlink = 1 for directories with more than 32K subdirs > > (EXT4_FEATURE_RO_COMPAT_DIR_NLINK). > > > > But in both those fs newly created directories will have nlink = 2. > > Is

About free space fragmentation, metadata write amplification and (no)ssd

So... today a real life story / btrfs use case example from the trenches at work... tl;dr 1) btrfs is awesome, but you have to carefully choose which parts of it you want to use or avoid 2) improvements can be made, but at least the problems relevant for this use case are managable and behaviour

Re: Linux next-20170407 failed to build on ARM due to usage of mod in btrfs code

On Sat, Apr 08, 2017 at 02:45:34PM -0300, Fabio Estevam wrote: > On Sat, Apr 8, 2017 at 1:02 PM, Icenowy Zheng wrote: > > Hello everyone, > > Today I tried to build a kernel with btrfs enabled on ARM, then when linking > > I met such an error: > > > > ``` > > fs/built-in.o: In

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

> I have no problem merging this patch into audit/next for v4.12, would > you prefer me to do that so at least this patch is merged? This would be fine. But, I think whoever takes the last 2 deletion patches should also take them. I'm not sure how that part works out. > It would probably make

Re: Linux next-20170407 failed to build on ARM due to usage of mod in btrfs code

On Sat, Apr 8, 2017 at 1:02 PM, Icenowy Zheng wrote: > Hello everyone, > Today I tried to build a kernel with btrfs enabled on ARM, then when linking > I met such an error: > > ``` > fs/built-in.o: In function `scrub_bio_end_io_worker': > acl.c:(.text+0x2f0450): undefined

Linux next-20170407 failed to build on ARM due to usage of mod in btrfs code

Hello everyone, Today I tried to build a kernel with btrfs enabled on ARM, then when linking I met such an error: ``` fs/built-in.o: In function `scrub_bio_end_io_worker': acl.c:(.text+0x2f0450): undefined reference to `__aeabi_uldivmod' fs/built-in.o: In function `scrub_extent_for_parity':

Re: Does btrfs get nlink on directories wrong? -- was Re: [PATCH 2/4] xfstests: Add first statx test [ver #5]

On Wed, Apr 05, 2017 at 03:32:30PM +0300, Amir Goldstein wrote: > On Wed, Apr 5, 2017 at 3:30 PM, David Sterba wrote: > > On Wed, Apr 05, 2017 at 11:53:41AM +0100, David Howells wrote: > >> I've added a test to xfstests that exercises the new statx syscall. > >> However, > >>

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

On Fri, Apr 7, 2017 at 8:57 PM, Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Audit timestamps are recorded in string format into > an audit buffer for a given context. > These mark the entry timestamps for the syscalls. > Use y2038 safe struct timespec64 to

Re: btrfs filesystem keeps allocating new chunks for no apparent reason

On 04/08/2017 01:16 PM, Hans van Kranenburg wrote: > On 04/07/2017 11:25 PM, Hans van Kranenburg wrote: >> Ok, I'm going to revive a year old mail thread here with interesting new >> info: >> >> [...] >> >> Now, another surprise: >> >> From the exact moment I did mount -o remount,nossd on this

Re: btrfs filesystem keeps allocating new chunks for no apparent reason

On 04/07/2017 11:25 PM, Hans van Kranenburg wrote: > Ok, I'm going to revive a year old mail thread here with interesting new > info: > > [...] > > Now, another surprise: > > From the exact moment I did mount -o remount,nossd on this filesystem, > the problem vanished. > >

Re: During a btrfs balance nearly all quotas of the subvolumes became exceeded

Markus Baier posted on Fri, 07 Apr 2017 16:17:10 +0200 as excerpted: > Hello btrfs-list, > > today a strange behaviour appered during the btrfs balance process. > > I started a btrfs balance operation on the /home subvolume that > contains, as childs, all the subvolumes for the home directories

Re: btrfs filesystem keeps allocating new chunks for no apparent reason

Hans van Kranenburg posted on Fri, 07 Apr 2017 23:25:29 +0200 as excerpted: > So, this is why putting your /var/log, /var/lib/mailman and /var/spool > on btrfs is a terrible idea. > > Because the allocator keeps walking forward every file that is created > and then removed leaves a blank spot