On 15.10.2018 09:25, Lu Fengqi wrote:
> The find_ref_head shouldn't return the first entry even if no exact match
> is found. So move the hidden behavior to higher level.
>
> Besides, remove the useless local variables in the btrfs_select_ref_head.
>
> Signed-off-by: Lu Fengqi
Reviewed-by: N
The find_ref_head shouldn't return the first entry even if no exact match
is found. So move the hidden behavior to higher level.
Besides, remove the useless local variables in the btrfs_select_ref_head.
Signed-off-by: Lu Fengqi
---
fs/btrfs/delayed-ref.c | 45 +++
> > +/*
> > + * These flags control the behavior of the remap_file_range function
> > pointer.
> > + *
> > + * RFR_SAME_DATA: only remap if contents identical (i.e. deduplicate)
> > + */
> > +#define RFR_SAME_DATA(1 << 0)
> > +
> > +#define RFR_VALID_FLAGS (RFR_SAME_DA
(Thanks for the comments on requiring to warn_on if we fail the device change.)
(This fixes an ugly bug, I appreciate if you have any further comments).
Its not that impossible to imagine that a device OR a btrfs image is
been copied just by using the dd or the cp command. Which in case both
the c
On Thu, Oct 11, 2018 at 01:51:37PM +0200, David Sterba wrote:
>On Thu, Oct 11, 2018 at 01:40:32PM +0800, Lu Fengqi wrote:
>> There is no functional change. Just improve readablity.
>>
>> PATCH 1-4 parameter cleanup patches
>> PATCH 5 cleanup about btrfs_select_ref_head
>> PATCH 6 switch int to boo
On Thu, Oct 11, 2018 at 02:45:04PM +0200, David Sterba wrote:
>On Thu, Oct 11, 2018 at 03:28:15PM +0300, Nikolay Borisov wrote:
>> > I noticed that there is a macro called SCRAMBLE_DELAYED_REFS in the
>> > extent-tree.c. I am a bit curious whether it has been forgotten by
>> > everyone, I have not
On Thu, Oct 11, 2018 at 03:28:15PM +0300, Nikolay Borisov wrote:
>
>
>On 11.10.2018 15:15, Lu Fengqi wrote:
>> On Thu, Oct 11, 2018 at 09:40:52AM +0300, Nikolay Borisov wrote:
>>>
>>>
>>> On 11.10.2018 08:40, Lu Fengqi wrote:
If the return value of find_ref_head() is NULL, the only possibility
On Fri, Oct 12, 2018 at 09:22:18PM +0100, Filipe Manana wrote:
> On Thu, Oct 11, 2018 at 5:13 AM Darrick J. Wong
> wrote:
> >
> > From: Darrick J. Wong
> >
> > A deduplication data corruption is exposed by fstests generic/505 on
> > XFS.
>
> (and btrfs)
>
> Btw, the generic test I wrote was in
On Sun, Oct 14, 2018 at 1:09 PM, Cerem Cem ASLAN wrote:
> Thanks for the explanation, I got it now. I still think this is
> related with my needs, so I'll keep an eye on this.
>
> What is the possible use case? I can think of only one scenario: You
> have a rootfs that contains a distro installer
On Sun, Oct 14, 2018 at 10:35:46AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 12, 2018 at 05:08:32PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > Back when the XFS reflink code only supported clone_file_range, we were
> > only able to return zero or negative error codes to u
Thanks for the explanation, I got it now. I still think this is
related with my needs, so I'll keep an eye on this.
What is the possible use case? I can think of only one scenario: You
have a rootfs that contains a distro installer and you want to
generate distro.img files which uses Btrfs under t
On Sun, Oct 14, 2018 at 6:20 AM, Cerem Cem ASLAN wrote:
> I'm not sure I could fully understand the desired achievement but it
> sounds like (or this would be an example of selective perception) it's
> somehow related with "creating reproducible snapshots"
> (https://unix.stackexchange.com/q/46245
> +static struct page *vfs_dedupe_get_page(struct inode *inode, loff_t offset)
> +{
> + struct address_space *mapping;
> + struct page *page;
> + pgoff_t n;
> +
> + n = offset >> PAGE_SHIFT;
> + mapping = inode->i_mapping;
> + page = read_mapping_page(mapping, n, NULL);
> +
> @@ -2531,14 +2531,11 @@ static loff_t ocfs2_remap_file_range(struct file
> *file_in, loff_t pos_in,
>struct file *file_out, loff_t pos_out,
>loff_t len, unsigned int remap_flags)
> {
> - int ret;
> -
> if (!remap_
> + bool is_dedupe = (remap_flags & RFR_SAME_DATA);
Btw, I think the code would be cleaner if we dropped this variable.
On Fri, Oct 12, 2018 at 05:08:32PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Back when the XFS reflink code only supported clone_file_range, we were
> only able to return zero or negative error codes to userspace. However,
> now that copy_file_range (which returns bytes copied) c
How is RFR_SHORT_DEDUPE so different from RFR_SAME_DATA + RFR_CAN_SHORTEN
that we need another flag for it?
On Fri, Oct 12, 2018 at 05:07:37PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Create a RFR_TO_SRC_EOF flag to explicitly declare that the caller wants
> the remap implementation to remap to the end of the source file, once
> the files are locked.
The name looks like a cat threw up
On Fri, Oct 12, 2018 at 05:06:58PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Plumb the remap flags through the filesystem from the vfs function
> dispatcher all the way to the prep function to prepare for behavior
> changes in subsequent patches.
>
> Signed-off-by: Darrick J. Won
> +/* Update inode timestamps and remove security privileges when remapping. */
> +int generic_remap_file_range_touch(struct file *file, bool is_dedupe)
> +{
> + int ret;
> +
> + /* If can't alter the file contents, we're done. */
> + if (is_dedupe)
> + return 0;
> +
> +
> unsigned (*mmap_capabilities)(struct file *);
> #endif
> ssize_t (*copy_file_range)(struct file *, loff_t, struct file *,
> loff_t, size_t, unsigned int);
> - int (*clone_file_range)(struct file *, loff_t, struct file *, loff_t,
> u64);
> - int (*dedupe_file_range)(struct f
Looks fine,
Reviewed-by: Christoph Hellwig
I'm not sure I could fully understand the desired achievement but it
sounds like (or this would be an example of selective perception) it's
somehow related with "creating reproducible snapshots"
(https://unix.stackexchange.com/q/462451/65781), no?
Chris Murphy , 14 Eki 2018 Paz, 02:05
tarihinde şun
On 2018/10/14 下午7:08, waxhead wrote:
> In case BTRFS fails to WRITE to a disk. What happens?
Normally it should return error when we flush disk.
And in that case, error will leads to transaction abort and the fs goes
RO to prevent further corruption.
> Does the bad area get mapped out somehow?
In case BTRFS fails to WRITE to a disk. What happens?
Does the bad area get mapped out somehow? Does it try again until it
succeed or until it "times out" or reach a threshold counter?
Does it eventually try to write to a different disk (in case of using
the raid1/10 profile?)
25 matches
Mail list logo
