On Monday 11 January 2016 03:59 PM, Sunil Mohan Adapa wrote:
[...]
> This mostly means that the patch is not necessary. We just need to
> create some test cases (based on existing cases for ext4) to make
> sure btrfs is building/running fine.
[...]
The 'error=remount-ro' field in the fstab will no
On Tuesday 12 January 2016 01:04 AM, Petter Reinholdtsen wrote:
> [Sunil Mohan Adapa]
>> With the proposed approach, we will have both the ways to mount and use,
>> that is, revert to an older snapshot.
>>
>> 1) Use 'btrfs set-default' to set the default subvolume and reboot.
>>
>> 2) Change the ar
[Sunil Mohan Adapa]
> With the proposed approach, we will have both the ways to mount and use,
> that is, revert to an older snapshot.
>
> 1) Use 'btrfs set-default' to set the default subvolume and reboot.
>
> 2) Change the arguments to mount in fstab and kernel boot parmeters like
> before using
On Monday 11 January 2016 07:50 PM, Petter Reinholdtsen wrote:
>
> I do no longer remember the details, but the goal when I went with this
> approach to picking the btrfs root was to be able to snapshot the
> current system (assuing / contain /etc/, /var/, /usr/ and everything
> else needed to run
I do no longer remember the details, but the goal when I went with this
approach to picking the btrfs root was to be able to snapshot the
current system (assuing / contain /etc/, /var/, /usr/ and everything
else needed to run the system), upgrade it, boot into the new system and
conclude that the
I believe, the patch can and must be simplified.
*Current state*: The current patch creates a subvol called "@" and then
makes a lot of code changes to various activities to make sure that all
the activities happen on that subvol. The main brtfs volume is mounted
and then root directory path (the
6 matches
Mail list logo
