On 15/01/2020 08:58, Steven Whitehouse wrote:
Hi,
On 15/01/2020 08:49, Andreas Gruenbacher wrote:
There's no point in sharing the internal structure of lock value blocks
with user space.
The reason that is in ondisk is that changing that structure is
something that needs to follow the same
On 15/01/2020 13:19, Bob Peterson wrote:
- Original Message -
Hi,
On 15/01/2020 09:24, Andreas Gruenbacher wrote:
On Wed, Jan 15, 2020 at 9:58 AM Steven Whitehouse
wrote:
On 15/01/2020 08:49, Andreas Gruenbacher wrote:
There's no point in sharing the internal structure of lock
- Original Message -
> Hi,
>
> On 15/01/2020 09:24, Andreas Gruenbacher wrote:
> > On Wed, Jan 15, 2020 at 9:58 AM Steven Whitehouse
> > wrote:
> >> On 15/01/2020 08:49, Andreas Gruenbacher wrote:
> >>> There's no point in sharing the internal structure of lock value blocks
> >>> with
Hi,
On 15/01/2020 09:24, Andreas Gruenbacher wrote:
On Wed, Jan 15, 2020 at 9:58 AM Steven Whitehouse wrote:
On 15/01/2020 08:49, Andreas Gruenbacher wrote:
There's no point in sharing the internal structure of lock value blocks
with user space.
The reason that is in ondisk is that changing
On Wed, Jan 15, 2020 at 9:58 AM Steven Whitehouse wrote:
> On 15/01/2020 08:49, Andreas Gruenbacher wrote:
> > There's no point in sharing the internal structure of lock value blocks
> > with user space.
>
> The reason that is in ondisk is that changing that structure is
> something that needs to
Hi,
On 15/01/2020 08:49, Andreas Gruenbacher wrote:
There's no point in sharing the internal structure of lock value blocks
with user space.
The reason that is in ondisk is that changing that structure is
something that needs to follow the same rules as changing the on disk
structures. So
There's no point in sharing the internal structure of lock value blocks
with user space.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/glock.h | 1 +
fs/gfs2/incore.h | 1 +
fs/gfs2/rgrp.c | 10 ++
include/uapi/linux/gfs2_ondisk.h |
