Re: [PATCH 0/7] Let user specify the kernel version for features

Hope we are in sync on.. 1. The term auto that you are using here refs to 'Progs default-features being updated at the _run time_'. 2. In the long run, mostly it would be: progs-version > LTS-kernel-version (for the reason that user would need fsck,tools.. etc) With the new -O comp=

Re: [PATCH 0/7] Let user specify the kernel version for features

Anand Jain wrote on 2015/11/27 06:17 +0800: Hope we are in sync on.. 1. The term auto that you are using here refs to 'Progs default-features being updated at the _run time_'. Yes. 2. In the long run, mostly it would be: progs-version > LTS-kernel-version (for the reason that user

Re: subvols and parents - how?

Christoph Anton Mitterer posted on Tue, 24 Nov 2015 22:25:50 +0100 as excerpted: >> Suppose you only want to rollback /, because some update screwed you >> up, >> but not /home, which is fine.  If /home is a nested subvolume, then >> you're now mounting the nested home subvolume from some other

implications of mixed mode

Dear list, if a larger RAID file system (say disk space of 8 TB in total) is created in mixed mode, what are the implications? >From reading the mailing list and the Wiki, I can think of the following: + less hassle with "false positive" ENOSPC - data and metadata have to have the same

Re: [PATCH v2] btrfs-progs: fsck: Fix a false alert where extent record has wrong metadata flag

On Fri, 2015-11-27 at 08:40 +0800, Qu Wenruo wrote: > But since there is no real error sure...  > feel free to keep using it or just re > format it with skinny-metadata. That's just onging =) Thanks for all your efforts in that issue =) Chris. smime.p7s Description: S/MIME cryptographic

Re: implications of mixed mode

Lukas Pirl wrote on 2015/11/27 12:54 +1300: Dear list, if a larger RAID file system (say disk space of 8 TB in total) is created in mixed mode, what are the implications? From reading the mailing list and the Wiki, I can think of the following: + less hassle with "false positive" ENOSPC

Re: implications of mixed mode

Lukas Pirl posted on Fri, 27 Nov 2015 12:54:57 +1300 as excerpted: > Dear list, > > if a larger RAID file system (say disk space of 8 TB in total) is > created in mixed mode, what are the implications? > > From reading the mailing list and the Wiki, I can think of the > following: > > + less

Re: [PATCH v2] btrfs-progs: fsck: Fix a false alert where extent record has wrong metadata flag

Christoph Anton Mitterer wrote on 2015/11/26 16:20 +0100: Hey. I can confirm that the new patch fixes the issue on both test filesystems. Thanks for working that out. I guess there's no longer a need to keep that old filesystems now?! Of course no need to keep. But since there is no real

Re: subvols and parents - how?

Christoph Anton Mitterer posted on Tue, 24 Nov 2015 22:25:50 +0100 as excerpted: >> Then there's the security angle to consider.  With the (basically, >> possibly modified as I suggested) flat layout, mounting something >> doesn't automatically give people in-tree access to nested subvolumes >>

Re: btrfs: poor performance on deleting many large files

Christoph Anton Mitterer posted on Fri, 27 Nov 2015 01:06:45 +0100 as excerpted: > And additionally, allow people to mount subvols with different > noatime/relatime/atime settings (unless that's already working)... that > way, they could enable it for things where they want/need it,... and >

Re: [auto-]defrag, nodatacow - general suggestions?(was: btrfs: poor performance on deleting many large files?)

Christoph Anton Mitterer posted on Thu, 26 Nov 2015 01:23:59 +0100 as excerpted: > Hey. > > I've worried before about the topics Mitch has raised. > Some questions. > > 1) AFAIU, the fragmentation problem exists especially for those files > that see many random writes, especially, but not

Re: btrfs: poor performance on deleting many large files

Christoph Anton Mitterer posted on Thu, 26 Nov 2015 19:25:47 +0100 as excerpted: > On Thu, 2015-11-26 at 16:52 +, Duncan wrote: >> For people doing snapshotting in particular, atime updates can be a big >> part of the differences between snapshots, so it's particularly >> important to set

Re: btrfs: poor performance on deleting many large files

On Thu, 2015-11-26 at 23:29 +, Duncan wrote: > > but only on meta-data blocks, right? > Yes. Okay... so it'll at most get the whole meta-data for a snapshot separately and not shared anymore... And when these are chained as in ZFS,.. it probably amplifies... i.e. a change deep down in the tree

kernel call trace during send/receive

Hey. Just got the following during send/receiving a big snapshot from one btrfs to another fresh one. Both under kernel 4.2.6, tools 4.3 The send/receive seems to continue however... Any ideas what that means? Cheers, Chris. Nov 27 01:52:36 heisenberg kernel: [ cut here

Re: btrfs: poor performance on deleting many large files

Mitchell Fossen wrote on 2015/11/25 15:49 -0600: On Mon, 2015-11-23 at 06:29 +, Duncan wrote: Using subvolumes was the first recommendation I was going to make, too, so you're on the right track. =:^) Also, in case you are using it (you didn't say, but this has been demonstrated to

Re: btrfs check help

> On Nov 25, 2015, at 8:44 PM, Qu Wenruo wrote: > > > > Vincent Olivier wrote on 2015/11/25 11:51 -0500: >> I should probably point out that there is 64GB of RAM on this machine and >> it’s a dual Xeon processor (LGA2011-3) system. Also, there is only Btrfs >>

How to detect / notify when a raid drive fails?

I'd like to run "mail" when a btrfs raid drive fails, but I don't know how to detect that a drive has failed. It don't see it in any docs. Otherwise I assume I would never know until enough drives fail that the filesystem stops working, and I'd like to know before that. - Ian Kelling -- To

Re: How to detect / notify when a raid drive fails?

Ian Kelling posted on Thu, 26 Nov 2015 21:14:57 -0800 as excerpted: > I'd like to run "mail" when a btrfs raid drive fails, but I don't know > how to detect that a drive has failed. It don't see it in any docs. > Otherwise I assume I would never know until enough drives fail that the > filesystem

Re: implications of mixed mode

On Fri, 27 Nov 2015 10:21:31 +0800 Qu Wenruo wrote: > And some extra pros and cons due to fixed(4K) small(compared to 16K > default) nodesize: > > + A little higher performance >node/leaf size is restricted to sectorsize, smaller node/leaf, >smaller range to

[PATCH] btrfs-progs: mkfs: Fix a wrong extent buffer size causing wrong superblock csum

For make_btrfs(), it's setting wrong buf size for last super block write out. The superblock size is always BTRFS_SUPER_INFO_SIZE, not cfg->sectorsize. And this makes mkfs.btrfs -f -s 8K fails. Fix it to BTRFS_SUPER_INFO_SIZE. Signed-off-by: Qu Wenruo --- Thanks

Re: [PATCH 00/25] Btrfs-convert rework to support native separate

On Thu, Nov 26, 2015 at 08:38:23AM +0800, Qu Wenruo wrote: > > As far as the conversion support stays, it's not a problem of course. I > > don't have a complete picture of all the actual merging conflicts, but > > the idea is to provide the callback abstraction v2 to allow ext2 and > > reiser plus

Re: [PATCH 00/25] Btrfs-convert rework to support native separate

On 11/26/2015 05:30 PM, David Sterba wrote: On Thu, Nov 26, 2015 at 08:38:23AM +0800, Qu Wenruo wrote: As far as the conversion support stays, it's not a problem of course. I don't have a complete picture of all the actual merging conflicts, but the idea is to provide the callback abstraction

Re: [PATCH 0/7] Let user specify the kernel version for features

With the new -O comp= option, the concern on user who want to make a btrfs for newer kernel is hugely reduced. NO!. actually new option -O comp= provides no concern for users who want to create _a btrfs disk layout which is compatible with more than one kernel_. above there are two

Re: [PATCH 0/7] Let user specify the kernel version for features

On 11/26/2015 07:18 PM, Anand Jain wrote: With the new -O comp= option, the concern on user who want to make a btrfs for newer kernel is hugely reduced. NO!. actually new option -O comp= provides no concern for users who want to create _a btrfs disk layout which is compatible with more

Re: [PATCH] btrfs-progs: mkfs: Fix a wrong extent buffer size causing wrong superblock csum

On Thu, Nov 26, 2015 at 04:15:55PM +0800, Qu Wenruo wrote: > For make_btrfs(), it's setting wrong buf size for last super block write > out. > The superblock size is always BTRFS_SUPER_INFO_SIZE, not > cfg->sectorsize. > > And this makes mkfs.btrfs -f -s 8K fails. > > Fix it to

Re: [PATCH v2] btrfs-progs: fsck: Fix a false alert where extent record has wrong metadata flag

On Wed, Nov 25, 2015 at 02:19:06PM +0800, Qu Wenruo wrote: > In process_extent_item(), it gives 'metadata' initial value 0, but for > non-skinny-metadata case, metadata extent can't be judged just from key > type and it forgot that case. > > This causes a lot of false alert in non-skinny-metadata

Re: [PATCH 00/25] Btrfs-convert rework to support native separate

On Thu, Nov 26, 2015 at 06:12:57PM +0800, Qu Wenruo wrote: > But I'm a little concerned about the unstable headers, unlike ext2 its > headers is almost stable but reiserfs seems not. Well, reiserfs is not developped nowadays and I think Jeff implemented the bits required for btrfs-convert. The

Re: [PATCH] btrfs: Support convert to -d dup for btrfs-convert

On Thu, Nov 19, 2015 at 05:26:22PM +0800, Zhao Lei wrote: > Since we will add support for -d dup for non-mixed filesystem, > kernel need to support converting to this raid-type. > > This patch remove limitation of above case. > > Signed-off-by: Zhao Lei Reviewed-by:

Re: [PATCH v3] btrfs-progs: mkfs: Enable -d dup for single device

On Thu, Nov 19, 2015 at 04:14:16PM -0500, Austin S Hemmelgarn wrote: > On 2015-11-19 04:36, Zhao Lei wrote: > > Signed-off-by: Zhao Lei > Seeing as I forgot to reply to the previous version after testing it, > I'll just reply here now that I've run this version through

Re: [PATCH 00/25] Btrfs-convert rework to support native separate

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/26/15 5:12 AM, Qu Wenruo wrote: > > > On 11/26/2015 05:30 PM, David Sterba wrote: >> On Thu, Nov 26, 2015 at 08:38:23AM +0800, Qu Wenruo wrote: As far as the conversion support stays, it's not a problem of course. I don't have a

Re: [PATCH v2] btrfs-progs: fsck: Fix a false alert where extent record has wrong metadata flag

Hey. I can confirm that the new patch fixes the issue on both test filesystems. Thanks for working that out. I guess there's no longer a need to keep that old filesystems now?! Cheers, Chris. On Thu, 2015-11-26 at 15:27 +0100, David Sterba wrote: > On Wed, Nov 25, 2015 at 02:19:06PM +0800, Qu

Re: btrfs send reproducibly fails for a specific subvolume after sending 15 GiB, scrub reports no errors

Hugo Mills posted on Tue, 24 Nov 2015 21:27:46 + as excerpted: [In the context of btrfs send...] >-p only sends the file metadata for the changes from the reference > snapshot to the sent snapshot. -c sends all the file metadata, but will > preserve the reflinks between the sent snapshot

Re: Using Btrfs on single drives

Russell Coker posted on Wed, 25 Nov 2015 18:20:25 +1100 as excerpted: > On Sun, 15 Nov 2015 03:01:57 PM Duncan wrote: >> That looks to me like native drive limitations. >> >> Due to the fact that a modern hard drive spins at the same speed no >> matter where the read/write head is located, when

Re: [4.3-rc4] scrubbing aborts before finishing

Martin Steigerwald posted on Wed, 25 Nov 2015 16:35:39 +0100 as excerpted: > I´d report a bug report, in case anyone would be interested. But if the > interest it like in this mailinglist post I can spare myself the time > for reporting via bugzilla. > > So does anyone at all care about this

Re: btrfs: poor performance on deleting many large files

Mitchell Fossen posted on Wed, 25 Nov 2015 15:49:58 -0600 as excerpted: > Also, is there a recommendation for relatime vs noatime mount options? I > don't believe anything that runs on the server needs to use file access > times, so if it can help with performance/disk usage I'm fine with >

[PATCH] btrfs-progs: docs: mkfs, implications of DUP on devices

We offer DUP but still depend on the hardware, to do the right thing. Signed-off-by: David Sterba --- To wider audience: feel free to suggest improvements to the manual page text if you think it's not clear or too technical etc. Documentation/mkfs.btrfs.asciidoc | 32

Re: [PATCH v2 1/5] btrfs-progs: introduce framework to check kernel supported features

On Tue, Nov 24, 2015 at 03:21:19PM -0500, Austin S Hemmelgarn wrote: > > I think you mean 2.6.37 here. > > 67377734fd24c3 "Btrfs: add support for mixed data+metadata block groups" > This brings up a rather important question: > Should compat-X.Y mean features that were considered usable in that >

Re: btrfs: poor performance on deleting many large files

On Thu, 2015-11-26 at 16:52 +, Duncan wrote: > For people doing snapshotting in particular, atime updates can be a > big > part of the differences between snapshots, so it's particularly > important > to set noatime if you're snapshotting. What everything happens when that is left at

vfs: move btrfs clone ioctls to common code

This patch set moves the existing btrfs clone ioctls that other file system have started to implement to common code, and allows the NFS server to export this functionality to remote systems. This work is based originally on my NFS CLONE prototype, which reused code from Anna Schumaker's NFS COPY

[PATCH 3/5] vfs: pull btrfs clone API to vfs layer

The btrfs ioctl clones are now adopted by other file systems: NFS since 4.3 and XFS a few kernel in the future, as well as the previous (incorrect) usage by CIFS. To avoid growth of various slightly incompatible implementation add one to the core VFS code. Note that clones are different from

[PATCH 4/5] nfsd: Pass filehandle to nfs4_preprocess_stateid_op()

From: Anna Schumaker This will be needed so COPY can look up the saved_fh in addition to the current_fh. Signed-off-by: Anna Schumaker --- fs/nfsd/nfs4proc.c | 16 +--- fs/nfsd/nfs4state.c | 5 ++--- fs/nfsd/state.h | 4

[PATCH 1/5] cifs: implement clone_file_range operation

And drop the fake support for the btrfs CLONE ioctl - SMB2 copies are chunked and do not actually implement clone semantics! Heavily based on a previous patch from Peng Tao. Signed-off-by: Christoph Hellwig --- fs/cifs/cifsfs.c | 25 ++ fs/cifs/cifsfs.h | 4 ++-

[PATCH 2/5] locks: new locks_mandatory_area calling convention

Pass a loff_t end for the last byte instead of the 32-bit count parameter to allow full file clones even on 32-bit architectures. While we're at it also drop the pointless inode argument and simplify the read/write selection. Signed-off-by: Christoph Hellwig --- fs/locks.c

[PATCH 5/5] nfsd: implement the NFSv4.2 CLONE operation

This is basically a remote version of the btrfs CLONE operation, so the implementation is fairly trivial. Made even more trivial by stealing the XDR code and general framework Anna Schumaker's COPY prototype. Signed-off-by: Christoph Hellwig --- fs/nfsd/nfs4proc.c | 47

Re: How to detect / notify when a raid drive fails?

On Thu, Nov 26, 2015, at 09:30 PM, Duncan wrote: > What generally happens now, however, is that the btrfs will note failures > attempting to write the device and start queuing up writes. If the > device reappears fast enough, btrfs will flush the queue and be back to > normal. Otherwise, you