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

    On Sun, 14 Feb 1999 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.020 / U:14.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site