linux-kernel - Re: [PATCH v11 00/21] Add support for NV-DIMMs to ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140930160841.GB5098@wil.cx>
Date:	Tue, 30 Sep 2014 12:08:41 -0400
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Valdis.Kletnieks@...edu
Cc:	Matthew Wilcox <willy@...ux.intel.com>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v11 00/21] Add support for NV-DIMMs to ext4

On Tue, Sep 30, 2014 at 10:53:47AM -0400, Valdis.Kletnieks@...edu wrote:
> On Tue, 30 Sep 2014 10:48:54 -0400, Matthew Wilcox said:
> 
> > No, it doesn't try to do that.  Wouldn't you be better served with an
> > LD_PRELOAD that forces O_DIRECT on?
> 
> Not when you don't want it on every file, and users are creating and
> deleting files once in a while.  A chattr-like command is easier and
> more scalable than rebuilding the LD_PRELOAD every time the list of
> files gets changed....

The more I think about this, the more I think this is a bad idea.
When you have a file open with O_DIRECT, your I/O has to be done in
512-byte multiples, and it has to be aligned to 512-byte boundaries
in memory.  If an unsuspecting application has O_DIRECT forced on it,
it isn't going to know to do that, and so all its I/Os will fail.
It'll also be horribly inefficient if a program has the file mmaped.

What problem are you really trying to solve?  Some big files hogging
the page cache?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/