On 10/26/2018 11:52 PM, Nikolay Borisov wrote:
On 26.10.18 г. 18:34 ч., Anand Jain wrote:
On 10/26/2018 11:02 PM, Nikolay Borisov wrote:
On 8.10.18 г. 21:28 ч., Anand Jain wrote:
We have a known bug in btrfs, that we let the device path be changed
after the device has been mounted.
On 26.10.18 г. 18:34 ч., Anand Jain wrote:
>
>
> On 10/26/2018 11:02 PM, Nikolay Borisov wrote:
>>
>>
>> On 8.10.18 г. 21:28 ч., Anand Jain wrote:
>>> We have a known bug in btrfs, that we let the device path be changed
>>> after the device has been mounted. So using this loop hole the new
On 10/26/2018 11:02 PM, Nikolay Borisov wrote:
On 8.10.18 г. 21:28 ч., Anand Jain wrote:
We have a known bug in btrfs, that we let the device path be changed
after the device has been mounted. So using this loop hole the new
copied device would appears as if its mounted immediately after
On 8.10.18 г. 21:28 ч., Anand Jain wrote:
> We have a known bug in btrfs, that we let the device path be changed
> after the device has been mounted. So using this loop hole the new
> copied device would appears as if its mounted immediately after its
> been copied. So this test case reproduces
On Tue, Oct 09, 2018 at 02:28:21AM +0800, Anand Jain wrote:
> We have a known bug in btrfs, that we let the device path be changed
> after the device has been mounted. So using this loop hole the new
> copied device would appears as if its mounted immediately after its
> been copied. So this test
We have a known bug in btrfs, that we let the device path be changed
after the device has been mounted. So using this loop hole the new
copied device would appears as if its mounted immediately after its
been copied. So this test case reproduces this issue.
For example:
Initially..