From: Linda Walsh <lkml@tlinx.org>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Subject: supporting laptops fs-semantic changes (was Re: Ext4 and the "30 second window of death")
Date: Mon, 06 Apr 2009 14:32:25 -0700 [thread overview]
Message-ID: <49DA74E9.9050702@tlinx.org> (raw)
In-Reply-To: <20090401174336.GA14726@srcf.ucam.org>
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
next prev parent reply other threads:[~2009-04-06 22:01 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-29 10:24 Ext4 and the "30 second window of death" Alberto Gonzalez
2009-03-31 12:25 ` Theodore Tso
2009-03-31 12:52 ` Alberto Gonzalez
2009-03-31 13:45 ` Theodore Tso
2009-03-31 14:45 ` Alberto Gonzalez
2009-04-01 0:04 ` Theodore Tso
2009-04-01 1:14 ` Alberto Gonzalez
2009-03-31 22:02 ` Alberto Gonzalez
2009-03-31 23:22 ` Andreas T.Auer
2009-04-01 1:25 ` Alberto Gonzalez
2009-04-01 1:50 ` Theodore Tso
2009-04-01 5:20 ` Sitsofe Wheeler
2009-04-01 15:12 ` Matthew Garrett
2009-04-01 17:35 ` Theodore Tso
2009-04-01 17:43 ` Matthew Garrett
2009-04-01 21:21 ` Ray Lee
2009-04-01 21:26 ` Matthew Garrett
2009-04-02 11:25 ` Sitsofe Wheeler
2009-04-02 18:22 ` david
2009-04-02 18:29 ` Matthew Garrett
2009-04-02 18:44 ` david
2009-04-02 20:07 ` Ray Lee
2009-04-02 20:59 ` Andreas T.Auer
2009-04-02 23:38 ` Theodore Tso
2009-04-03 0:00 ` Matthew Garrett
2009-04-03 7:33 ` Pavel Machek
2009-04-03 8:14 ` Andreas T.Auer
2009-04-02 22:36 ` Bron Gondwana
2009-04-02 23:46 ` Matthew Garrett
2009-04-03 0:55 ` david
2009-04-03 1:06 ` Matthew Garrett
2009-04-03 1:16 ` david
2009-04-03 1:19 ` Matthew Garrett
2009-04-03 1:24 ` david
2009-04-03 1:36 ` Matthew Garrett
2009-04-03 3:08 ` david
2009-04-03 13:42 ` Matthew Garrett
2009-04-03 4:54 ` Theodore Tso
2009-04-03 11:09 ` Sitsofe Wheeler
2009-04-03 13:07 ` Alberto Gonzalez
2009-04-03 13:45 ` Matthew Garrett
2009-04-02 18:34 ` Nick Piggin
2009-04-02 18:38 ` Matthew Garrett
2009-04-02 18:56 ` Nick Piggin
2009-04-02 23:47 ` Matthew Garrett
2009-04-03 0:59 ` david
2009-04-03 1:09 ` Matthew Garrett
2009-04-03 1:17 ` david
2009-04-03 1:22 ` Matthew Garrett
2009-04-03 2:22 ` Ric Wheeler
2009-04-02 21:47 ` david
2009-04-06 21:32 ` Linda Walsh [this message]
2009-04-02 11:37 ` Sitsofe Wheeler
2009-04-01 8:51 ` Andreas T.Auer
2009-04-03 7:13 ` Bojan Smojver
2009-04-05 4:07 ` Bojan Smojver
2009-04-05 4:51 ` Bojan Smojver
2009-04-05 5:41 ` Bojan Smojver
2009-04-05 17:27 ` Ed Tomlinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49DA74E9.9050702@tlinx.org \
--to=lkml@tlinx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.