Re: attacking btrfs filesystems via UUID collisions?

On 12/06/2015 09:51 AM, Christoph Anton Mitterer wrote: On Sat, 2015-12-05 at 13:19 +, Duncan wrote: The problem with btrfs is that because (unlike traditional filesystems) it's multi-device, it needs some way to identify what devices belong to a particular filesystem. Sure, but that

Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

Hi Liu, I was studying on how block reservation works, and making some modifications in reserve_metadata_bytes to understand better what it does. Then suddenly I saw this problem. I guess it depends on which value of "flush" parameter is passed to reserve_metadata_bytes. Alex. On Thu, Dec 3,

Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. But flush_space will not convert this to 0, and will also return 1. As a result, reserve_metadata_bytes will think that flush_space failed, and may potentially return this value "1" to the caller (depends how reserve_metadata_bytes

Re: compression disk space saving - what are your results?

On Sunday 06 December 2015 04:21:30 Duncan wrote: >Marc Joliet posted on Sat, 05 Dec 2015 15:11:51 +0100 as excerpted: >> I do think it's interesting that compression (even with LZO) seems to >> have offset the extra space wastage caused by autodefrag. > >I've seen (I think) you mention that twice

Re: Fixing recursive fault and parent transid verify failed

On 12/07/2015 02:57 PM, Alistair Grant wrote as excerpted: > Fixing recursive fault, but reboot is needed For the record: I saw the same message (incl. hard lockup) when doing a balance on a single-disk btrfs. Besides that, the fs works flawlessly (~60GB, usage: no snapshots, ~15 lxc

Fixing recursive fault and parent transid verify failed

Hi, (Resending as it looks like the first attempt didn't get through, probably too large, so logs are now in dropbox) I have a btrfs volume which is raid1 across two spinning rust disks, each 2TB. When trying to access some files from a another machine using sshfs the server machine has crashed

Re: [PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

Naohiro Aota wrote on 2015/12/07 11:59 +0900: On Sat, Dec 5, 2015 at 10:35 AM, Qu Wenruo wrote: On 12/04/2015 01:37 PM, Naohiro Aota wrote: This series address an issue of btrfsck to restore infinite number of same file into `lost+found' directory. The issue occur

Re: Very various speed of grep operation on btrfs partition

Михаил Гаврилов posted on Mon, 07 Dec 2015 02:16:08 +0500 as excerpted: > 2015-12-04 17:59 GMT+05:00 Austin S Hemmelgarn : >> Well, what other things are accessing the filesystem at the same time? >> If you've got something like KDE running with the 'semantic desktop' >>

Re: Scrub on btrfs single device only to detect errors, not correct them?

Chris Murphy posted on Sun, 06 Dec 2015 13:42:57 -0700 as excerpted: > On Sun, Dec 6, 2015 at 12:15 PM, Jon Panozzo > wrote: >> Just to confirm, is the sole purpose of supporting scrub on single >> btrfs devices to detect errors, but not to correct them? > > If that

Re: [PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

On Sat, Dec 5, 2015 at 10:35 AM, Qu Wenruo wrote: > > > On 12/04/2015 01:37 PM, Naohiro Aota wrote: >> >> This series address an issue of btrfsck to restore infinite number of >> same file into `lost+found' directory. The issue occur on a file which >> is linked from two

Re: [PATCH 2/4] vfs: pull btrfs clone API to vfs layer

On Thu, Dec 03, 2015 at 12:59:50PM +0100, Christoph Hellwig wrote: > The btrfs clone ioctls are now adopted by other file systems, with NFS > and CIFS already having support for them, and XFS being under active > development. To avoid growth of various slightly incompatible > implementations, add

Re: Very various speed of grep operation on btrfs partition

2015-12-04 17:59 GMT+05:00 Austin S Hemmelgarn : > Well, what other things are accessing the filesystem at the same time? If > you've got something like KDE running with the 'semantic desktop' stuff > turned on, than that will seriously impact the performance of other things

Scrub on btrfs single device only to detect errors, not correct them?

Just to confirm, is the sole purpose of supporting scrub on single btrfs devices to detect errors, but not to correct them? Best Regards, Jonathan Panozzo Lime Technology, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: Scrub on btrfs single device only to detect errors, not correct them?

On Sun, Dec 6, 2015 at 12:15 PM, Jon Panozzo wrote: > Just to confirm, is the sole purpose of supporting scrub on single btrfs > devices to detect errors, but not to correct them? If that single device metadata profile is DUP, then it will correct those. If there is

Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

On Sun, Dec 06, 2015 at 12:32:31PM +0200, Alex Lyakas wrote: > do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. > But flush_space will not convert this to 0, and will also return 1. > As a result, reserve_metadata_bytes will think that flush_space failed, > and may potentially

[PATCH] btrfs: Introduce new mount option to disable tree log replay

Introduce a new mount option "nologreplay" to co-operate with "ro" mount option to get real readonly mount, like "norecovery" in ext* and xfs. Since the new parse_options() need to check new flags at remount time, so add a new parameter for parse_options(). Signed-off-by: Qu Wenruo