Re: [PATCH] Use of getblk differs between locations

From: Andrew Morton (akpm_at_osdl.org)
Date: 10/11/05

  • Next message: Robert Crocombe: "PS/2 Keyboard under 2.6.x" 
    Date:	Mon, 10 Oct 2005 18:07:05 -0700
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>

    Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> wrote:
    >
    > On Mon, 10 Oct 2005, Andrew Morton wrote:
    >
    > > Anton Altaparmakov <aia21@cam.ac.uk> wrote:
    > >>
    > >> > Maybe the best solution is neither one nor another. Testing and failing
    > >> > gracefully seems better.
    > >> >
    > >> > What do you think?
    > >>
    > >> I certainly agree with you there. I neither want a deadlock nor
    > >> corruption. (-:
    > >
    > > Yup. In the present implementation __getblk_slow() "cannot fail". It's
    > > conceivable that at some future stage we'll change __getblk_slow() so that
    > > it returns NULL on an out-of-memory condition.
    >
    > The question is if it is desired --- it will make bread return NULL on
    > out-of-memory condition, callers will treat it like an IO error, skipping
    > access to the affected block, causing damage on perfectly healthy
    > filesystem.

    Yes, that is a bit dumb. A filesystem might indeed want to take different
    action for ENOMEM versus EIO.

    > I liked what linux-2.0 did in this case --- if the kernel was out of
    > memory, getblk just took another buffer, wrote it if it was dirty and used
    > it. Except for writeable loopback device (where writing one buffer
    > generates more dirty buffers), it couldn't deadlock.

    Wouldn't it be better if bread() were to return ERR_PTR(-EIO) or
    ERR_PTR(-ENOMEM)? Big change.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Robert Crocombe: "PS/2 Keyboard under 2.6.x"

    Relevant Pages

    • Re: [00/17] Large Blocksize Support V3
      ... to lock the filesystem block and prevent any updates to it, ... get 128 pages into a bio so all we've done churned some in memory ... I/O no faster than the current code. ... We can't use buffer heads - they can only point ...
      (Linux-Kernel)
    • Re: -mm -> 2.6.13 merge status
      ... >> mean that the success rate for crashing kernels is not high enough for ... > other crashdump methods. ... This is not a filesystem but a filesystem + ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: silent semantic changes with reiser4
      ... > Marketed product: a set of hooks, the wider the better, no matter how ... remove these features and make it a "normal" filesystem. ... you changed into a meta directory using ftp and some manage to break ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] fsblock
      ... what is the buffer layer? ... buffer layer as in the buffer cache of unix: ... There are filesystem APIs to access the block device, ...
      (Linux-Kernel)
    • Re: silent semantic changes with reiser4
      ... on a sufficiently fast box; don't work when there are ... Remember that the Solaris attribute model is just another filesystem ... inodes that delete themselves when other inodes are changed creep me ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)