lkml.org 
[lkml]   [1996]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.2.0 wishlist
Hi,

On Sat, 15 Jun 1996 02:02:40 +0200 (MET DST), Marek Michalkiewicz
<marekm@i17linuxb.ists.pwr.wroc.pl> said:

> Thomas Koenig:
>> Also, NFS V3 wouldn't hurt at all.

> More ideas for the wishlist - first the easy ones:

> - handle the SAK and Ctrl-Alt-Del in raw mode (there is a small
> patch for this available somewhere I think).
> - allow processes run by normal users to lock a page or two
> (subject to RLIMIT_MEMLOCK) so that sensitive data won't end
> up in swap space. Currently only the superuser can do that
> (still subject to the resource limit).

Yes. This comes under the heading of having per-user resource limits
on top of the existing per-process limits.

> Now something harder:

> - the ext2 filesystem is quite good at recovering from crashes,
> but it could be made even better (and probably only slightly
> slower) by always syncing dirty buffers to disk in the right
> order. For example, write data blocks, then indirect blocks
> pointing to them, then inode blocks pointing to the data or
> indirect blocks. This way the filesystem on disk would stay
> consistent all the time.

Heh, don't start me on this!

Ordered writes have major problems. You want a list? OK: you get bad
cyclic dependencies (especially between inode blocks and bitmaps,
since multiple inodes get stored in a single block); if your data is
always being written, you NEVER get to update the inode; and Unixware
have got a broad-ranging patent for ordered filesystem writes anyway.
<sigh>.

Ganger proposed a neat alternative called "soft updates" which
involves doing roll-back of inconsistent data on write, and which is
immune from cyclic dependencies. However, the complexity is enormous.

Neither of these mechanisms truly guarantee ordered atomic
transactions on the filesystem. IMHO the real solution to this is to
do limited filesystem journalling. We only have to do it for
metadata, and the volume of data should be pretty low most of the
time.

Cheers,
Stephen.
--
Stephen Tweedie <sct@dcs.ed.ac.uk>
Department of Computer Science, Edinburgh University, Scotland.


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.063 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site