| 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
| ||
|
Date: Tue, 30 Sep 2014 17:10:26 +0000 From: "Zuckerman, Boris" <borisz@...com> To: Matthew Wilcox <willy@...ux.intel.com>, "Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu> CC: Matthew Wilcox <matthew.r.wilcox@...el.com>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: RE: [PATCH v11 00/21] Add support for NV-DIMMs to ext4 > > 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? > -- Page cache? As another copy in RAM? NV_DIMMs may be viewed as a caching device. This caching can be implemented on the level of NV block/offset or may have some hints from FS and applications. Temporary files is one example. They may not need to hit NV domain ever. Some transactional journals or DB files is another example. They may stay in RAM until power off. -- 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/
Powered by blists - more mailing lists