Going back to this discussion,
On Mon, Nov 30, 2015 at 01:46:15PM +0800, Qu Wenruo wrote:
> To be honest, how many guys really unhappy with current default features
> behavior *except* you?
Me too.
Anand's summary matches my view of how we should do it:
". Do it at run time for the running
On Wed, Feb 03, 2016 at 11:50:38AM +0100, David Sterba wrote:
> Going back to this discussion,
>
> On Mon, Nov 30, 2015 at 01:46:15PM +0800, Qu Wenruo wrote:
> > To be honest, how many guys really unhappy with current default features
> > behavior *except* you?
>
> Me too.
>
> Anand's summary
David Sterba wrote on 2016/02/03 11:50 +0100:
Going back to this discussion,
On Mon, Nov 30, 2015 at 01:46:15PM +0800, Qu Wenruo wrote:
To be honest, how many guys really unhappy with current default features
behavior *except* you?
Me too.
Anand's summary matches my view of how we should
(Most of the technical reasoning were already discussed so I won't
repeat them here).
And jolting for new technical reasons finds only these..
What if the fs is not only for kernel to mount, but also a boot
partition for grub?
Do you need to check the grub2 version? Check if this is a
Anand Jain wrote on 2015/11/30 12:54 +0800:
(Most of the technical reasoning were already discussed so I won't
repeat them here).
And jolting for new technical reasons finds only these..
What if the fs is not only for kernel to mount, but also a boot
partition for grub?
Do you need
On 11/27/2015 04:41 PM, Anand Jain wrote:
I meant, it can be done in packaging level and it's much easier to do.
Its all about trade off, and there is no right or wrong, so is tough
to arrive at a conclusion even before this was implemented. Below are
the choices considered, now
Hope we are in sync on..
1.
The term auto that you are using here refs to
'Progs default-features being updated at the _run time_'.
2.
In the long run, mostly it would be:
progs-version > LTS-kernel-version
(for the reason that user would need fsck,tools.. etc)
With the new -O comp=
Anand Jain wrote on 2015/11/27 06:17 +0800:
Hope we are in sync on..
1.
The term auto that you are using here refs to
'Progs default-features being updated at the _run time_'.
Yes.
2.
In the long run, mostly it would be:
progs-version > LTS-kernel-version
(for the reason that user
With the new -O comp= option, the concern on user who want to make a
btrfs for newer kernel is hugely reduced.
NO!. actually new option -O comp= provides no concern for users who
want to create _a btrfs disk layout which is compatible with more
than one kernel_. above there are two
On 11/26/2015 07:18 PM, Anand Jain wrote:
With the new -O comp= option, the concern on user who want to make a
btrfs for newer kernel is hugely reduced.
NO!. actually new option -O comp= provides no concern for users who
want to create _a btrfs disk layout which is compatible with more
Anand Jain wrote on 2015/11/25 20:08 +0800:
Sometimes users may want to have a btrfs to be supported on multiple
kernel version. A simple example, USB drive can be used with multiple
system running different kernel versions. Or in a data center a SAN
LUN could be mounted on any system with
Anand Jain wrote on 2015/11/26 14:07 +0800:
On 11/26/2015 10:02 AM, Qu Wenruo wrote:
Anand Jain wrote on 2015/11/25 20:08 +0800:
Sometimes users may want to have a btrfs to be supported on multiple
kernel version. A simple example, USB drive can be used with multiple
system running
Sometimes users may want to have a btrfs to be supported on multiple
kernel version. A simple example, USB drive can be used with multiple
system running different kernel versions. Or in a data center a SAN
LUN could be mounted on any system with different kernel version.
Thanks for providing
On 11/26/2015 10:02 AM, Qu Wenruo wrote:
Anand Jain wrote on 2015/11/25 20:08 +0800:
Sometimes users may want to have a btrfs to be supported on multiple
kernel version. A simple example, USB drive can be used with multiple
system running different kernel versions. Or in a data center a SAN
14 matches
Mail list logo
