Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 7:10 AM, Miguel Ojeda wrote: > On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote: >> On 03/09/2018 04:07 PM, Andrew Morton wrote: >>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: >>>

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote: > On 03/09/2018 04:07 PM, Andrew Morton wrote: >> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: >> >>> When max() is used in stack array size calculations from literal values >>> (e.g. "char

Re: Change of Ownership of the filesystem content when cloning a volume

10.03.2018 02:13, Saravanan Shanmugham (sarvi) пишет: > > Netapp’s storage system, has the concept of snapshot/clones. > And when I create a clone from a snapshot, I can give/change ownership of > entire tree in the volume to a different userid. You are probably mistaken. NetApp FlexClone

Re: [PATCH 0/3] btrfs-progs: Split original mode check to its own

On 2018年03月10日 00:56, David Sterba wrote: > On Tue, Feb 06, 2018 at 03:02:20PM +0800, Qu Wenruo wrote: >> This time, there are 2 patches too large to reach mail list, so please >> fetch the whole patchset from github as usual: >> https://github.com/adam900710/btrfs-progs/tree/split_check_part2 >

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

On Fri, 9 Mar 2018 22:15:23 -0500 Steven Rostedt wrote: > Sorry for the spam. A little more spam ;-) I know what happened, as I'm able to recreate it. For those that use claws-mail, be careful. I clicked on the email I wanted to reply to. Then I must have hit the down

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

I don't know what the hell happened, but claws mail just inserted a ton of people into the Cc (I didn't add you). I noticed it just after I hit send. The added Cc looks like it came from the email right after the email I was replying to "Subject: Re: [PATCH v3] kernel.h: Skip single-eval logic on

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On 03/09/2018 04:07 PM, Andrew Morton wrote: > On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: > >> When max() is used in stack array size calculations from literal values >> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler >> thinks this is a

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

On Fri, 09 Mar 2018 21:34:45 -0500 Steven Rostedt wrote: > 2 files changed, 1050 insertions(+), 1273 deletions(-) BTW, it's a bit bigger impact than 223 deletions. As I added a lot of comments to explain the logic better. Removing comments and white space from the

zerofree btrfs support?

Hi. Just wondered... was it ever planned (or is there some equivalent) to get support for btrfs in zerofree? Thanks, Chris. -- 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: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 5:31 PM, Kees Cook wrote: > > WTF, gmail just blasted HTML into my explicitly plain-text email?! > Apologies... There's more now in your email, I think maybe it's triggered by your signature file and some gmail web interface bug. Or it just tries to

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 5:30 PM, Kees Cook wrote: > -- > Kees Cook > Pixel SecurityOn > [...] WTF, gmail just blasted HTML into my explicitly plain-text email?! Apologies... -- Kees Cook Pixel SecurityOn Fri, Mar 9, 2018 at 5:30 PM, Kees Cook mailto:keesc...@chromium.org;

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 4:38 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 4:32 PM, Andrew Morton > wrote: >> >> I wonder which gcc versions actually accept Kees's addition. Ah, my old nemesis, gcc 4.4.4. *sob* > Note that we

[PATCH 4.4 12/36] btrfs: Dont clear SGID when inheriting ACLs

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jan Kara commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 4:32 PM, Andrew Morton wrote: > > I wonder which gcc versions actually accept Kees's addition. Note that we already do have this pattern, as seen by: git grep -2 __builtin_choose_expr | grep -2 __builtin_constant_p which show

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, 9 Mar 2018 16:28:51 -0800 Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 4:07 PM, Andrew Morton > wrote: > > > > A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear > > to know that __builtin_constant_p(x) is

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 4:07 PM, Andrew Morton wrote: > > A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear > to know that __builtin_constant_p(x) is a constant. Or something. LOL. I suspect it might be that it wants to evaluate

Re: [PATCH] btrfs-progs: dump-tree: add degraded option

On 03/10/2018 12:23 AM, David Sterba wrote: On Thu, Feb 22, 2018 at 10:00:11PM +0800, Anand Jain wrote: btrfs inspect dump-tree cli picks the disk with the largest generation to read the root tree, even when all the devices were not provided in the cli. But in 2 disks RAID1 you may need to

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: > When max() is used in stack array size calculations from literal values > (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler > thinks this is a dynamic calculation due to the single-eval logic, which >

call trace on btrfs send/receive

Hey. The following still happens with 4.15 kernel/progs: btrfs send -p oldsnap newsnap | btrfs receive /some/other/fs Mar 10 00:48:10 heisenberg kernel: WARNING: CPU: 5 PID: 32197 at /build/linux-PFKtCE/linux-4.15.4/fs/btrfs/send.c:6487 btrfs_ioctl_send+0x48f/0xfb0 [btrfs] Mar 10 00:48:10

Change of Ownership of the filesystem content when cloning a volume

Netapp’s storage system, has the concept of snapshot/clones. And when I create a clone from a snapshot, I can give/change ownership of entire tree in the volume to a different userid. Is something like that possible in BTRFS? We are looking to use CopyOnWrite to snapshot nightly build

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 1:10 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote: >> When max() is used in stack array size calculations from literal values >> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]",

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote: > When max() is used in stack array size calculations from literal values > (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler > thinks this is a dynamic calculation due to the single-eval logic, which >

[PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

When max() is used in stack array size calculations from literal values (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler thinks this is a dynamic calculation due to the single-eval logic, which is not needed in the literal case. This change removes several accidental stack

Re: Btrfs remounted read-only due to ENOSPC in btrfs_run_delayed_refs

On 9.03.2018 21:03, Martin Svec wrote: > Being curious, how do you know that my global rsv is almost unused? During > backups, I see that > the usage is sometimes very close to the 512 MiB limit. I tried to increase > the limit to 1 GiB but it > didn't help. Well according to your output:

Re: Ongoing Btrfs stability issues

On Mar 9, 2018, at 3:54 AM, Nikolay Borisov wrote: > >> Sorry, I clearly missed that one. I have applied the patch you referenced >> and rebooted the VM in question. This morning we had another FS failure on >> the same machine that caused it to go into readonly mode. This

Re: Btrfs remounted read-only due to ENOSPC in btrfs_run_delayed_refs

Dne 9.3.2018 v 17:36 Nikolay Borisov napsal(a): > > On 23.02.2018 16:28, Martin Svec wrote: >> Hello, >> >> we have a btrfs-based backup system using btrfs snapshots and rsync. >> Sometimes, >> we hit ENOSPC bug and the filesystem is remounted read-only. However, >> there's >> still plenty of

Re: [PATCH v2 06/10] btrfs-progs: kernel-lib: Port kernel sort() to btrfs-progs

On Thu, Feb 22, 2018 at 09:43:37AM +0800, Qu Wenruo wrote: > > > On 2018年02月21日 23:40, David Sterba wrote: > > On Fri, Feb 09, 2018 at 03:44:24PM +0800, Qu Wenruo wrote: > >> Used by later btrfs_alloc_chunk() rework. > > > > We have the libc provided qsort, so please don't pull another > >

Re: Inconsistence between sender and receiver

On Fri, Mar 09, 2018 at 09:45:30AM +0300, Andrei Borzenkov wrote: > 09.03.2018 08:38, Liu Bo пишет: > > On Thu, Mar 08, 2018 at 09:15:50AM +0300, Andrei Borzenkov wrote: > >> 07.03.2018 21:49, Liu Bo пишет: > >>> Hi, > >>> > >>> In the following steps[1], if on receiver side has got > >>> changed

Re: How to replace a failed drive in btrfs RAID 1 filesystem

On 2018-03-09 11:53, Paul Richards wrote: Fantastic response!  Thank you. I haven’t investigated how broken the failed drive is, I just shutdown as soon as I noticed. The 3 drives were 8, 8 and 2 TB.  The 2TB one failed and I’m replacing it with a new 8TB.  So the new drive is indeed

Re: [PATCH 0/3] btrfs-progs: Split original mode check to its own

On Tue, Feb 06, 2018 at 03:02:20PM +0800, Qu Wenruo wrote: > This time, there are 2 patches too large to reach mail list, so please > fetch the whole patchset from github as usual: > https://github.com/adam900710/btrfs-progs/tree/split_check_part2 I missed this patch series, sorry. The changes

Re: [PATCH 1/4] btrfs-progs: Limit inline extent below page size

On Thu, Mar 01, 2018 at 10:47:44AM +0800, Qu Wenruo wrote: > Kernel doesn't support to drop extent inside an inlined extent. > And kernel tends to limit inline extent just below sectorsize, so also > limit it in btrfs-progs. > > This fixes unexpected -EOPNOTSUPP error from __btrfs_drop_extents()

Re: How to replace a failed drive in btrfs RAID 1 filesystem

On 2018-03-09 11:02, Paul Richards wrote: Hello there, I have a 3 disk btrfs RAID 1 filesystem, with a single failed drive. Before I attempt any recovery I’d like to ask what is the recommended approach? (The wiki docs suggest consulting here before attempting recovery[1].) The system is

Re: Btrfs remounted read-only due to ENOSPC in btrfs_run_delayed_refs

On 23.02.2018 16:28, Martin Svec wrote: > Hello, > > we have a btrfs-based backup system using btrfs snapshots and rsync. > Sometimes, > we hit ENOSPC bug and the filesystem is remounted read-only. However, there's > still plenty of unallocated space according to "btrfs fi usage". So I think

Re: [PATCH] btrfs-progs: dump-tree: add degraded option

On Thu, Feb 22, 2018 at 10:00:11PM +0800, Anand Jain wrote: > btrfs inspect dump-tree cli picks the disk with the largest generation > to read the root tree, even when all the devices were not provided in > the cli. But in 2 disks RAID1 you may need to know what's in the disks > individually, so

Re: [PATCH v2 1/3] btrfs-progs: check/lowmem: Fix the incorrect error message of check_extent_data_item

On Thu, Mar 08, 2018 at 04:13:27PM +0800, Qu Wenruo wrote: > > > On 2018年02月28日 18:13, Lu Fengqi wrote: > > Instead of the disk_bytenr and disk_num_bytes of the extent_item which the > > file extent references, we should output the objectid and offset of the > > file extent. And the leaf may be

How to replace a failed drive in btrfs RAID 1 filesystem

Hello there, I have a 3 disk btrfs RAID 1 filesystem, with a single failed drive. Before I attempt any recovery I’d like to ask what is the recommended approach? (The wiki docs suggest consulting here before attempting recovery[1].) The system is powered down currently and a replacement drive

Re: [PATCH] btrfs-progs: dump-super: Don't verify csum if csum type or size is unknown

On Tue, Mar 06, 2018 at 10:16:51AM +0800, Qu Wenruo wrote: > Reported-by: Ken Swenson > Signed-off-by: Qu Wenruo Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v2] btrfs-progs: free-space-cache: Enhance free space cache free space check

On Thu, Mar 08, 2018 at 03:02:31PM +0800, Qu Wenruo wrote: > When we found free space difference between free space cache and block > group item, we just discard this free space cache. > > Normally such difference is caused by btrfs_reserve_extent() called by > delalloc which is out of a

Re: [PATCH v2] btrfs-progs: free-space-cache: Enhance free space cache free space check

On Fri, Mar 09, 2018 at 10:06:02AM +0200, Nikolay Borisov wrote: > >>> + * space cache has less free space, and both kernel just discard > >>> + * such cache. But if we find some case where free space cache > >>> + * has more free space, this means under certain case

Re: Btrfs remounted read-only due to ENOSPC in btrfs_run_delayed_refs

On 9.03.2018 17:04, Martin Svec wrote: > Nobody knows? > > I'm particularly interested why debug space_info 4 shows negative (unsigned > 18446744072120172544) > value as free metadata space, please see the original report. Is it a bug in > dump_space_info(), or > metadata reservations can

Re: [PATCH v2] Btrfs: scrub: batch rebuild for raid56

On Wed, Mar 07, 2018 at 12:08:09PM -0700, Liu Bo wrote: > In case of raid56, writes and rebuilds always take BTRFS_STRIPE_LEN(64K) > as unit, however, scrub_extent() sets blocksize as unit, so rebuild > process may be triggered on every block on a same stripe. > > A typical example would be that

Re: Btrfs remounted read-only due to ENOSPC in btrfs_run_delayed_refs

Nobody knows? I'm particularly interested why debug space_info 4 shows negative (unsigned 18446744072120172544) value as free metadata space, please see the original report. Is it a bug in dump_space_info(), or metadata reservations can temporarily exceed the total space, or is it an

Re: dmesg flooded with "Very big device. Trying to use READ CAPACITY(16)" with 8TB HDDs

On Thu, Mar 08, 2018 at 12:18:04PM +0100, Menion wrote: > Actually this path can be taken in few occurrency > > 1) device probe, only when the device is plugged or detected the first time > 2) revalidate_disk fops of block device > > Is it possible that BTRFS every 5 minutes call the

Re: [PATCH] Btrfs: scrub: batch rebuild for raid56

On Wed, Mar 07, 2018 at 05:22:08PM +0200, Nikolay Borisov wrote: > > > On 7.03.2018 16:43, David Sterba wrote: > > On Tue, Mar 06, 2018 at 11:22:21AM -0700, Liu Bo wrote: > >> On Tue, Mar 06, 2018 at 11:47:47AM +0100, David Sterba wrote: > >>> On Fri, Mar 02, 2018 at 04:10:37PM -0700, Liu Bo

[PATCH] btrfs: sort and group mount option definitions

Sort mount options by the primary name, followed by the 'no-' counterpart if it exists. Group the deprecated and debugging options. Enum and token defintions are synced. Signed-off-by: David Sterba --- fs/btrfs/super.c | 139

Re: [PATCH v2] btrfs: Add nossd_spread mount option

On Thu, Mar 08, 2018 at 10:48:48AM -0800, Howard McLauchlan wrote: > Btrfs has two mount options for SSD optimizations: ssd and ssd_spread. > Presently there is an option to disable all SSD optimizations, but there > isn't an option to disable just ssd_spread. > > This patch adds a mount option

Re: Ongoing Btrfs stability issues

> Sorry, I clearly missed that one. I have applied the patch you referenced and > rebooted the VM in question. This morning we had another FS failure on the > same machine that caused it to go into readonly mode. This happened after > that device was experiencing 100% I/O utilization for some

Re: [PATCH 1/2] Btrfs: fiemap: pass correct bytenr when fm_extent_count is zero

On 9.03.2018 11:01, robbieko wrote: > Nikolay Borisov 於 2018-03-07 19:15 寫到: >> On  7.03.2018 12:27, robbieko wrote: >>> Nikolay Borisov 於 2018-03-07 18:19 寫到: On  7.03.2018 10:20, robbieko wrote: > From: Robbie Ko > >  # mount /dev/vdb5 /mnt/btrfs >

Re: [PATCH 1/2] Btrfs: fiemap: pass correct bytenr when fm_extent_count is zero

Nikolay Borisov 於 2018-03-07 19:15 寫到: On 7.03.2018 12:27, robbieko wrote: Nikolay Borisov 於 2018-03-07 18:19 寫到: On  7.03.2018 10:20, robbieko wrote: From: Robbie Ko  # mount /dev/vdb5 /mnt/btrfs  # dd if=/dev/zero bs=16K count=4 oflag=dsync of=/mnt/btrfs/file  #

Re: [PATCH v2] btrfs-progs: free-space-cache: Enhance free space cache free space check

On 9.03.2018 01:27, Qu Wenruo wrote: > > > On 2018年03月08日 22:05, Nikolay Borisov wrote: >> >> >> On 8.03.2018 09:02, Qu Wenruo wrote: >>> When we found free space difference between free space cache and block >>> group item, we just discard this free space cache. >>> >>> Normally such