[PATCH RFC RESEND] btrfs: harden agaist duplicate fsid

2018-10-14 Thread Anand Jain
(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

Re: [PATCH 0/6] Some trivail cleanup about dealyed-refs

2018-10-14 Thread Lu Fengqi
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

Re: [PATCH 5/6] btrfs: simplify btrfs_select_ref_head and cleanup some local variables

2018-10-14 Thread Lu Fengqi
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

Re: [PATCH 5/6] btrfs: simplify btrfs_select_ref_head and cleanup some local variables

2018-10-14 Thread Lu Fengqi
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

Re: reproducible builds with btrfs seed feature

2018-10-14 Thread Chris Murphy
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

Re: reproducible builds with btrfs seed feature

2018-10-14 Thread Cerem Cem ASLAN
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

Re: reproducible builds with btrfs seed feature

2018-10-14 Thread Chris Murphy
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" >

Re: reproducible builds with btrfs seed feature

2018-10-14 Thread Cerem Cem ASLAN
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

Re: BTRFS bad block management. Does it exist?

2018-10-14 Thread Qu Wenruo
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?

BTRFS bad block management. Does it exist?

2018-10-14 Thread waxhead
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?)