On 11/13/2018 11:47 PM, Anand Jain wrote:
On 11/13/2018 11:31 PM, David Sterba wrote:
On Mon, Oct 01, 2018 at 09:31:04PM +0800, Anand Jain wrote:
+ /*
+ * we are going to replace the device path, make sure its the
+ * same device if the device mounted
+ */
+
On 11/13/2018 11:31 PM, David Sterba wrote:
On Mon, Oct 01, 2018 at 09:31:04PM +0800, Anand Jain wrote:
+ /*
+ * we are going to replace the device path, make sure its the
+ * same device if the device mounted
+ */
+ if (device->bdev) {
+
On 11/13/2018 10:31 AM, David Sterba wrote:
On Mon, Oct 01, 2018 at 09:31:04PM +0800, Anand Jain wrote:
+ /*
+ * we are going to replace the device path, make sure its the
+ * same device if the device mounted
+ */
+ if (device->bdev) {
+ struct
On Mon, Oct 01, 2018 at 09:31:04PM +0800, Anand Jain wrote:
> >> + /*
> >> + * we are going to replace the device path, make sure its the
> >> + * same device if the device mounted
> >> + */
> >> + if (device->bdev) {
> >> + struct block_device
On 10/01/2018 07:17 PM, Austin S. Hemmelgarn wrote:
On 2018-10-01 04:56, Anand Jain wrote:
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 copies of the btrfs will have the same fsid. If on the
On 2018-10-01 04:56, Anand Jain wrote:
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 copies of the btrfs will have the same fsid. If on the system with
automount enabled, the copied FS gets scanned.
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 copies of the btrfs will have the same fsid. If on the system with
automount enabled, the copied FS gets scanned.
We have a known bug in btrfs, that we
