Hi Sargun,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.13-rc1 next-20170717]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sargun
Hi guys,
We are facing some issues with a btrfs filesystem on one of our department
filers.
The problem started pretty much one week ago, when I decided to purge old
snapshots.
Until then we were doing daily btrfs snapshots to have a quick backup.
What then happened was that btrfs-cleaner kicked
2017-07-16 18:06 GMT+02:00 Marc MERLIN :
> On Sun, Jul 16, 2017 at 04:01:53PM +0200, Giuseppe Della Bianca wrote:
>> > On Fri, Jul 14, 2017 at 06:22:16PM -0700, Marc MERLIN wrote:
>> > > Dear Chris and other developers,
>> ]zac[
>> > Others on this thread with the same error: did anyone recover fro
For now that code just return true
Later more complex heuristic code will be added
Signed-off-by: Timofey Titovets
---
fs/btrfs/compression.c | 30 ++
fs/btrfs/compression.h | 2 ++
fs/btrfs/inode.c | 10 +-
3 files changed, 37 insertions(+), 5 deletion
On Fri, Jul 07, 2017 at 11:40:04AM -0600, Chris Murphy wrote:
> On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov wrote:
> > 07.07.2017 19:42, Chris Murphy пишет:
> >> I'm digging through piles of list emails and not really finding an
> >> answer to this. Maybe it's Friday and I'm just confused...
This is a minimal patch intended to be backported to older kernels.
We're going to extend the string specifying the compression method and
this would fail on kernels before that change (the string is compared
exactly).
Relax the string matching only to the prefix, ie. ignoring anything that
goes a
On Sat, Jul 15, 2017 at 12:52:34PM +0800, Anand Jain wrote:
> On 07/13/2017 09:18 PM, David Sterba wrote:
> > Currently, the BTRFS_INODE_NOCOMPRESS will prevent any compression on a
> > given file, except when the mount is force-compress. As users have
> > reported on IRC, this will also prevent co
On Mon, Jul 17, 2017 at 06:47:07PM +0200, David Sterba wrote:
> On Sat, Jul 15, 2017 at 12:52:34PM +0800, Anand Jain wrote:
> > On 07/13/2017 09:18 PM, David Sterba wrote:
> > > Currently, the BTRFS_INODE_NOCOMPRESS will prevent any compression on a
> > > given file, except when the mount is force-
On Sat, Jul 15, 2017 at 06:45:38AM +, Paul Jones wrote:
> > Now the compression set through property will act same as '-o compress-
> > force'. Before this patch is was like '-o compress'.
> > I am ok to fix that patch with a new patch.
>
> While we are at it, would it be possible to add an op
So it basically looks good, I could not resist and rewrote the changelog
and comments. There's one code fix:
On Mon, Jul 17, 2017 at 04:52:58PM +0300, Timofey Titovets wrote:
> -static inline int inode_need_compress(struct inode *inode)
> +static inline int inode_need_compress(struct inode *inode,
An improved version of patch https://patchwork.kernel.org/patch/9838439/ after
Anand's comment that the change also affects properties, this time it addresses
the core problem first and then changes the defrag priority over nocompress.
David Sterba (4):
btrfs: rename variable holding per-inode c
This is preparatory for separating inode compression requested by defrag
and set via properties. This will fix a usability bug when defrag will
reset compression type to NONE. If the file has compression set via
property, it will not apply anymore (until next mount or reset through
command line).
Currently, the BTRFS_INODE_NOCOMPRESS will prevent any compression on a
given file, except when the mount is force-compress. As users have
reported on IRC, this will also prevent compression when requested by
defrag (btrfs fi defrag -c file).
The nocompress flag is set automatically by filesystem
Add new value for compression to distinguish between defrag and
property. Previously, a single variable was used and this caused clashes
when the per-file 'compression' was set and a defrag -c was called.
The property-compression is loaded when the file is open, defrag will
overwrite the same vari
Signed-off-by: David Sterba
---
fs/btrfs/ioctl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 5d28d53e1b81..37226b13e289 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1286,6 +1286,7 @@ int btrfs_defrag_file(s
libOSTree makes use of bind mounts during startup to support multiple
fs trees on any file system for the purpose of atomic updates and
rollback.
Example during boot:
Jul 17 15:18:42 frawhide.localdomain systemd[779]: var.mount:
Executing: /usr/bin/mount
/sysroot/ostree/deploy/fedora-workstation/
Hello,
my raid1 (2 x HDD 4TB) started in RO mode,
what procedure should I do to get my btrfs working again?
# uname -a
Linux black 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017
x86_64 GNU/Linux
# btrfs --version
btrfs-progs v4.11.1
# btrfs f sh
Label: 'ssd' uuid: dc54bfb3-64ad-4e39-a
On Mon, Jul 17, 2017 at 5:12 PM, Tom, OE1TKT wrote:
> Hello,
>
> my raid1 (2 x HDD 4TB) started in RO mode,
> what procedure should I do to get my btrfs working again?
>
> # uname -a
> Linux black 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017
> x86_64 GNU/Linux
> # btrfs --version
> bt
For any one who wants to try it, it can be get from my repo:
https://github.com/gujx2017/btrfs-progs/tree/offline_scrub
In this v5, just make some small fixups of comments on the left 15 patches,
according to problems pointed out by David when mergering the first 5 patches
of this patchset.
And re
Brennecke, Simon posted on Mon, 17 Jul 2017 08:03:33 + as excerpted:
> I understand that purging snapshots is a complex operation, but we
> somehow need to reduce the load this causes during working hours.
> Are there any ways to tell btrfs-cleaner to suspend or reduce its
> operations?
>
>
20 matches
Mail list logo
