[lkml]   [2002]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] ext2 and ext3 block reservations can be bypassed
On Mon, May 13, 2002 at 06:22:42AM +0200, Kasper Dupont wrote:
> Alexander Viro wrote:
> >
> > On Mon, 13 May 2002, Peter Chubb wrote:
> >
> > > This is why in SVr4, struct cred is cloned at open time, and passed
> > > down to each VFS operation.
> >
> > That doesn't work for shared mappings over holes. Unfortunately.
> > Yes, credentials cache a-la 4.4BSD would help in many cases, but
> > we have no reasonably credentials when kswapd writes a dirty page
> > on disk. It _can_ cause allocations. And many processes might've
> > touched that page until it finally got written out - which credentials
> > would you use?
> I'd rather have the check done when the page gets dirty in the
> first place. Refuse the CoW if there is not diskspace to write
> it back. Right now we can go beyond the diskspace we are allowed
> to use and we will silently loose data if we go beyond the
> available diskspace.

So, the way this would work (presumably) is that space gets reserved on
the filesystem as soon as the page goes dirty, if space is not presently
allocated for that page. The process would receive a SIGBUS if they
attempt to write to the page, but backing store reservation failed, as
they do when, eg., there's an IO error on a page or some such.

If the mapping was held by more than one process, and one had permission
to dirty the page and the other did not, then whose credentials should
get used would just be a matter of which one writes first. If the disk
is full for users and root dirties the page first, then the user can
re-dirty it. If the user dirties it first, then the user receives
SIGBUS. If the disk is full for everyone, then either one would receive
the signal.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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