linux-kernel - supporting laptops fs-semantic changes (was Re: Ext4 and the "30 second window of death")

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 for Android: free password hash cracker in your pocket

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

Message-ID: <49DA74E9.9050702@tlinx.org>
Date:	Mon, 06 Apr 2009 14:32:25 -0700
From:	Linda Walsh <lkml@...nx.org>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:	Matthew Garrett <mjg59@...f.ucam.org>
Subject: supporting laptops fs-semantic changes (was Re: Ext4 and the "30
 second window of death")

Matthew Garrett wrote:
>> The other subtlety comes if we add fsync() suppression to laptop mode
-----
    Perhaps this has already been suggested, but rather than
adding all these semantics to the core file-system / kernel routines,
wouldn't it be preferable to allow some 'layering' of a pseudo,
memory-based file-system, OVER some 'real' file system (OR), definable
set of files (under a subdir...or same device...or whatever).

The semantics of when the virtual-fs would sync to the physical-fs/files
controlled via mount options.  Physical disk writes would be controlled by
selectively ignoring or honoring various "sync" events (time expired,
sync, fsync).

This could allow file-systems with different 'needs' (DB, or otherwise)
to be treated differently. 

The advantage of another layer, is you could define _how much_ buffering
you wanted to allocate to a filesystem (or file-set).  Maybe it's tolerable
losing a audio-recording of a talk, so large buff + don't sync 'cept when
full is fine.  Sensitive filesystems(or sets) (i.e. db's), could be set
with buffers to hold largest 'single-writes', but sync/fsyncs are what
they are.

An optimization could provide for read/writes through the user-mem 
controlled
buffered 'fs', to do direct I/O rather than into normal file-buffs where
possible, since presumably all accesses to a file would go through the
layer or not.

Wouldn't require application changing, and wouldn't require changing
well defined, lower-level kernel-filesystem operations.

Just a thought.
Linda

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