On 09/19/2016 04:36 PM, Christoph Anton Mitterer wrote:
On Mon, 2016-09-19 at 16:07 -0400, Chris Mason wrote:
That's in the blockdev command (blockdev --setro /dev/xxx).
Well, I know that ;-) ... but I bet most end-user don't (just as most
end-users assume mount -r is truly ro)...
It's a
On Mon, 2016-09-19 at 16:07 -0400, Chris Mason wrote:
> That's in the blockdev command (blockdev --setro /dev/xxx).
Well, I know that ;-) ... but I bet most end-user don't (just as most
end-users assume mount -r is truly ro)...
At least this is nowadays documented at the mount manpage... so in a
On 09/19/2016 03:52 PM, Christoph Anton Mitterer wrote:
On Mon, 2016-09-19 at 13:18 -0400, Austin S. Hemmelgarn wrote:
- even mounting a fs ro, may cause it to be changed
This would go to the UseCases
My same argument about the UUID issues applies here, just without
the
security aspect.
On Mon, 2016-09-19 at 13:18 -0400, Austin S. Hemmelgarn wrote:
> > > - even mounting a fs ro, may cause it to be changed
> >
> > This would go to the UseCases
> My same argument about the UUID issues applies here, just without
> the
> security aspect.
I personally could agree to have that
+1 for all your changes with the following comments in addition...
On Mon, 2016-09-19 at 17:27 +0200, David Sterba wrote:
> That's more like a usecase, thats out of the scope of the tabular
> overview. But we have an existing page UseCases that I'd like to
> transform to a more structured and
On 2016-09-19 11:27, David Sterba wrote:
Hi,
On Thu, Sep 15, 2016 at 04:14:04AM +0200, Christoph Anton Mitterer wrote:
In general:
- I think another column should be added, which tells when and for
which kernel version the feature-status of each row was
revised/updated the last time and
Hi,
On Thu, Sep 15, 2016 at 04:14:04AM +0200, Christoph Anton Mitterer wrote:
> In general:
> - I think another column should be added, which tells when and for
> which kernel version the feature-status of each row was
> revised/updated the last time and especially by whom.
> If a core dev
On Thu, Sep 15, 2016 at 07:54:26AM -0400, Austin S. Hemmelgarn wrote:
> > I'd like to help creating/maintaining this bug overview. A good start
> > would be to just crawl through all stable kernels and some distro
> > kernels and see which commits show up in fs/btrfs.
> >
> As of right now, we
Am Donnerstag, 15. September 2016, 07:54:26 CEST schrieb Austin S. Hemmelgarn:
> On 2016-09-15 05:49, Hans van Kranenburg wrote:
> > On 09/15/2016 04:14 AM, Christoph Anton Mitterer wrote:
[…]
> I specifically do not think we should worry about distro kernels though.
> If someone is using a
On Thu, Sep 15, 2016 at 5:54 AM, Austin S. Hemmelgarn
wrote:
>
>
> I specifically do not think we should worry about distro kernels though.
It will be essentially impossible to keep such a thing up to date.
It's difficult in the best case scenario to even track upstream's
On 2016-09-15 05:49, Hans van Kranenburg wrote:
On 09/15/2016 04:14 AM, Christoph Anton Mitterer wrote:
Hey.
As for the stability matrix...
In general:
- I think another column should be added, which tells when and for
which kernel version the feature-status of each row was
On 09/15/2016 04:14 AM, Christoph Anton Mitterer wrote:
> Hey.
>
> As for the stability matrix...
>
> In general:
> - I think another column should be added, which tells when and for
> which kernel version the feature-status of each row was
> revised/updated the last time and especially by
Hey.
As for the stability matrix...
In general:
- I think another column should be added, which tells when and for
which kernel version the feature-status of each row was
revised/updated the last time and especially by whom.
If a core dev makes a statement on a particular feature, this
13 matches
Mail list logo