On Mon, Jul 13, 2020 at 09:46:31AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series has two parts: the first one picks up Dave's patch to avoid
> invalidation entierly for reads, picked up deep down from the btrfs iomap
> thread. The second one falls back to buffered writes if
Hi,
this patch series contains fixes to avoid compile warnings for gcc
version 10.
There might be some points for code sharing which I ignored right now
and leave the code as it is.
Also I added a patch to more log functionality in cases that a key value
config entry isn't successful parsed.
-
This patch fixes the following compiler warning:
config.c:269:26: warning: ‘val’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
269 |o->file_int = val ? 1 : 0;
The fix just init's val to 0 to have a fallback if parsing fails.
---
dlm_controld/config.c | 2 +-
1 file
This patch fixes the following compiler warning:
daemon_cpg.c:2158:12: warning: ‘run’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
2158 | run->info.reply_count++;
It's fixed by just init the used variable to NULL and use it only if
it's not NULL.
---
This patch fixes in dlm_controld all -Wstringop-truncation warnings.
There exists two different cases inside the code:
1. string buffer without null termination:
Code work as expected in this case a pragma is introduced to ignore the
warning.
2. string buffer with null termination:
The
This patch adds more log_error() functionality in cases if parsing of
key value pairs fails so the user get notice about it.
---
dlm_controld/config.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/dlm_controld/config.c b/dlm_controld/config.c
index
On Mon, Jul 13, 2020 at 08:39:20AM -0700, Darrick J. Wong wrote:
> -ENOTBLK is already being used as a "magic" return code that means
> "retry this direct write as a buffered write". Shouldn't we use that
> instead?
>
> -EREMCHG was a private hack we put in XFS for the one case where a
> direct
On Mon, Jul 13, 2020 at 12:55:09PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 13, 2020 at 09:46:33AM +0200, Christoph Hellwig wrote:
> > Failing to invalid the page cache means data in incoherent, which is
> > a very bad state for the system. Always fall back to buffered I/O
> > through the page
On 2020/07/13 16:51, Christoph Hellwig wrote:
> Failing to invalid the page cache means data in incoherent, which is
s/in incoherent/is incoherent
> a very bad state for the system. Always fall back to buffered I/O
> through the page cache if we can't invalidate mappings.
>
> Signed-off-by:
On 09/07/2020 05.25, Dave Chinner wrote:
Nobody's proposing changing Direct I/O to exclusively work through the
pagecache. The proposal is to behave less weirdly when there's already
data in the pagecache.
No, the proposal it to make direct IO behave *less
deterministically* if there is
10 matches
Mail list logo
