lkml.org 
[lkml]   [1999]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: fsync on large files


On Sun, 14 Feb 1999 Ralf.Sieger@gmx.net wrote:

>
> I took a look at fs/buffer.c in 2.0.36 and compared it with 2.2.1.
> What I found was
> 1. We do a lock_kernel() on each sys_fsync().
> So all other processes using this lock_have to wait... Why?

No, they haven't. kernel_lock affects nothing if the process
doesn't run at this moment. It protects processes on *different* CPUs from
simultaneous running in the kernel. It's an attribute of task and if the
task decides to sleep it is removed (and restored as soon as it wakes up).

> 2. Plus we ensure we get the semaphore
>
> /* We need to protect against concurrent writers.. */
> down(&inode->i_sem);
>
> So I have problems to get it. Since we called lock_kernel() we are the ony
> on in this pice of code.
>
> So AFAIK wheter the kernel lock is unneccessary or the semaphore or both?
Neither. Imagine the following situation: process A calls fsync()
and sleeps on IO. In the meanwhile process B wakes up and starts messing
with the file. After a while it sleeps on IO too. Process A wakes up and
finds some interesting changes ;-/ And struct file (and to less extent
dcache) management still isn't SMP-safe, so we need kernel_lock hold.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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