[lkml]   [2002]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectLinus' email account is full. - Fwd: Mail System Error - Returned Mail
Linus' email account appears to be full if we can believe this returned email:

>From: Mail Administrator <>
>Reply-To: Mail Administrator <>
>Subject: Mail System Error - Returned Mail
>Date: Fri, 8 Feb 2002 15:14:23 -0500
>This Message was undeliverable due to the following reason:
>The user(s) account is temporarily over quota.
>Please reply to
>if you feel this message to be in error.
>Reporting-MTA: dns;
>Arrival-Date: Fri, 8 Feb 2002 15:14:23 -0500
>Received-From-MTA: dns; (
>Final-Recipient: RFC822; <>
>Action: failed
>Status: 4.2.2
>X-Actual-Recipient: RFC822; <>
>Received: from ([])
> by with ESMTP
> id
> <>
> for <>; Fri, 8 Feb 2002 15:14:23 -0500
>Received: from ([]
> by with esmtp (Exim 3.34 #1)
> id 16ZHOo-0007Tk-00; Fri, 08 Feb 2002 20:13:34 +0000
>Message-Id: <>
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Fri, 08 Feb 2002 20:14:32 +0000
>From: Anton Altaparmakov <>
>Subject: Re: [RFC] New locking primitive for 2.5
>Cc: Christoph Hellwig <>,Ingo Molnar <>,
> yodaiken <>,Martin Wirth <>,
> linux-kernel <>,akpm <>,
> torvalds <>,rml <>
>In-Reply-To: <>
>References: <>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>At 16:51 08/02/02, Nigel Gamble wrote:
>> > No. i_sem should be split into a spinlock for short-time accessed
>> > fields that get written to even if the file content is only read (i.e.
>> > atime) and a read-write semaphore.
>>Read-write semaphores should never be used. As others have pointed out,
>>they cause really intractable priority inversion problems (because a
>>high priority writer will often have to wait for an unbounded number of
>>lower priority readers, some of which may have called a blocking
>>function while holding the read lock).
>>Note that I'm not talking about read-write spinlocks, which are (or
>>should be) held for a short, bounded time and can't be held over a
>>blocking call, so they are not quite so problematic.
>Read-write semaphores have their use and the current Linux implementation
>(big reader/occasional writer) guarantees that the writer is not starved
>as incoming read locks are put to sleep as soon as a write lock request
>comes in, even if that is sleeping waiting for the old readlocks to be
>released (unless the readers are holding the semaphore forever in which
>case this is the programmers fault and not the rw semaphore
>implementations fault). [I should add I only am familliar with the i386
>implementation but I assume the others are the same.]
>The value of allowing multiple cpus to read the same data simultaneously
>by far offsets the priority problems IMVHO. At least the way I am using rw
>semaphores in ntfs it is. Readlocks are grabbed loads and loads of times
>to serialize meta data access in the page cache while writelocks are a
>minute number in comparison and because the data required to be accessed
>may not be cached in memory (page cache page is not read in, is swapped
>out, whatever) a disk access may be required which means a rw spin lock is
>no good. In fact ntfs would be the perfect candidate for automatic rw
>combi locks where the locking switches from spinning to sleeping if the
>code path reaches a disk access. I can't use a manually controlled lock as
>the page cache lookups are done via the mm/filemap.c access functions
>which are the only ones who can know if a disk access is required or not
>so ntfs would never know if it is going to sleep or not so unless the
>locks had autodetection of whether to spin or sleep they would be useless.
>I guess the point I am trying to make is that both rw semaphores and combi
>locks are not bad per se but, as all other locking mechanisms, they should
>be used in situations appropriate for their locktype and their
> "I've not lost my mind. It's backed up on tape somewhere." - Unknown
>Anton Altaparmakov <aia21 at> (replace at with @)
>Linux NTFS Maintainer / WWW:
>ICQ: 8561279 / WWW:

"I've not lost my mind. It's backed up on tape somewhere." - Unknown
Anton Altaparmakov <aia21 at> (replace at with @)
Linux NTFS Maintainer / WWW:
ICQ: 8561279 / WWW:

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:18    [W:0.188 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site