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] [day] [month] [year] [list]
Date:	Wed, 07 Jan 2009 12:35:42 -0500
From:	Chris Snook <csnook@...hat.com>
To:	Eric Hopper <hopper@...ifarious.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: nosync, an idea for general filesystem mount flag

Eric Hopper wrote:
> Maybe somebody has thought of this before.  But I think it would be
> useful to have a mount flag telling the filesystem layer that a certain
> filesystem never ever needs to be synced, even when the 'sync' system
> call is called.
> 
> My /tmp, for example, is reformatted on each and every boot.  There is
> no reason for anything written to /tmp to ever hit the disk.  The only
> reason is to make room for something else in memory.
> 
> I think this could potentially help out notebooks that only had solid
> state drives.
> 
> Anyway, just a random thought,

This is why tmpfs was written, but if you're using an SSD with large erase 
blocks, and want to avoid setting up a swap partition, you could put the 
filesystem on a loop device instead.  The sync calls would be absorbed as writes 
to the non-sync backing file.  It's slightly more complicated to set up, and 
slightly less flexible, but the next generation SSDs won't have problems with 
random write performance, so the convenience of implementing such an option 
would be rather short-lived.  It's not a fundamentally evil idea, but it just 
doesn't seem to be worth the effort, particularly to maintain it for the rest of 
eternity.

-- Chris
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ