1. Forum
  2. FidoNet
  3. linux.debian.user

  • Re: Buffering of short-lived writes (was: is there a way to use a work

    From Nicolas George@3:633/10 to All on Monday, January 05, 2026 14:20:01
    Subject: Re: Buffering of short-lived writes (was: is there a way to use a work buffer in Linux bash? ...)

    tomas@tuxteam.de (HE12025-12-30):
    "No space left on device" is handled by the fs code, when it decides
    where to put a block. No need to actually write the block to disk.
    Possibly some fs's permanent data are updated and thus scheduled
    for write -- again a job for the buffer cache, which has to honour
    itself ordering constraints (what to write first, etc.)

    You are thinking about it too shallowly.

    ?No space left on device? is not just a matter of how much free space
    there is, it depends highly on the specifics of the filesystem, and
    possibly on fine details about the created file. Therefore, the metadata
    of the filessytem must be updated for the first file before deciding if
    the second file can be written.

    And then, the metadata is updated again for the second file, on top of
    the changes for the first file. That makes it impossible to just discard
    the changes done in the cache before they are written to the device.

    What could happen is that the metadata changes are written but the data
    blocks are marked not dirty before being written.

    Regards,

    --
    Nicolas George

    --- PyGate Linux v1.5.2
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Michael Paoli@3:633/10 to All on Tuesday, January 06, 2026 22:50:01
    Subject: Re: Buffering of short-lived writes (was: is there a way to use a work buffer in Linux bash? ...)

    If space is an issue, ENOSPC would generally be returned by write(2),
    however, it's also possible for close(2) to return ENOSPC.
    So, generally OS / file system code, would at least have the blocks
    reserved (at least tracked in memory/state, if not written to drive)
    to be able to successfully complete the write (and likely also at least
    some reserved blocks, so, e.g., if I/O error occurs on some block(s),
    then other blocks may be used to still successfully flush the data
    to the drive).
    But note also that even simply overwriting an existing file block
    can result in ENOSPC, e.g. if the file is sparse and that block isn't allocated, or if the filesystem uses compression, and the newly written
    data would require additional block(s) that aren't available.
    And both write(2) and close(2) may also return EIO (I/O error).
    Those are also reasons why it's good for programs to generally
    explicitly close their files and check the return results on those
    close system calls.

    On Mon, Jan 5, 2026 at 5:15?AM Nicolas George <george@nsup.org> wro
    te:

    tomas@tuxteam.de (HE12025-12-30):
    "No space left on device" is handled by the fs code, when it decides
    where to put a block. No need to actually write the block to disk.
    Possibly some fs's permanent data are updated and thus scheduled
    for write -- again a job for the buffer cache, which has to honour
    itself ordering constraints (what to write first, etc.)

    You are thinking about it too shallowly.

    ?No space left on device? is not just a matter of how muc
    h free space
    there is, it depends highly on the specifics of the filesystem, and
    possibly on fine details about the created file. Therefore, the metadata
    of the filessytem must be updated for the first file before deciding if
    the second file can be written.

    And then, the metadata is updated again for the second file, on top of
    the changes for the first file. That makes it impossible to just discard
    the changes done in the cache before they are written to the device.

    What could happen is that the metadata changes are written but the data blocks are marked not dirty before being written.

    Regards,

    --
    Nicolas George


    --- PyGate Linux v1.5.2
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)