Le 20/10/2018 à 10:39, Cerem Cem ASLAN a écrit :
> You don't even need dd_rescue or something for RaspberryPi creation,
> you may use
> https://github.com/aktos-io/dcs-tools#cloning-a-target-into-a-new-target
That's interesting, but a bit overkill for my needs : I'll stay with my
simple script
On 10/21/2018 05:31 PM, Filipe Manana wrote:
On Sun, Oct 21, 2018 at 10:20 AM Nikolay Borisov wrote:
On 21.10.2018 10:16, Filipe Manana wrote:
On Mon, Nov 13, 2017 at 2:26 AM Anand Jain wrote:
Make sure missing device is included in the alloc list when it is
scanned on a mounted FS.
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
On Sun, Oct 21, 2018 at 10:20 AM Nikolay Borisov wrote:
>
>
>
> On 21.10.2018 10:16, Filipe Manana wrote:
> > On Mon, Nov 13, 2017 at 2:26 AM Anand Jain wrote:
> >>
> >> Make sure missing device is included in the alloc list when it is
> >> scanned on a mounted FS.
> >>
> >> This test case needs
On 21.10.2018 10:16, Filipe Manana wrote:
> On Mon, Nov 13, 2017 at 2:26 AM Anand Jain wrote:
>>
>> Make sure missing device is included in the alloc list when it is
>> scanned on a mounted FS.
>>
>> This test case needs btrfs kernel patch which is in the ML
>> [PATCH] btrfs: handle
On Mon, Nov 13, 2017 at 2:26 AM Anand Jain wrote:
>
> Make sure missing device is included in the alloc list when it is
> scanned on a mounted FS.
>
> This test case needs btrfs kernel patch which is in the ML
> [PATCH] btrfs: handle dynamically reappearing missing device
> Without the kernel
On Sun, Oct 21, 2018 at 6:05 AM Andrew Nelson wrote:
>
> Also, is the drive in a safe state to use? Is there anything I should
> run on the drive to check consistency?
It should be in a safe state. You can verify it running "btrfs check
/dev/" (it's a readonly operation).
If you are able to
