4 ms·

There is now a way to mark processes as OOM-killer exempt https://backdrift.org/oom-killer-how-to-create-oom-exclusions-in-linux https://backdrift.org/oom-kill

by throwaway2048 7y ago

There is now a way to mark processes as OOM-killer exempt https://backdrift.org/oom-killer-how-to-create-oom-exclusions-in-linux https://backdrift.org/oom-killer-how-to-create-oom-exclusion... Part of the issue with processes stuck in D state (waiting for the kernel to do something) is that it is deeply tied into kernel assumptions about things like NFS, NFS is stateless, and theoretically severs can appear and disappear at will, and operations will keep working when it comes back. You can make NFS a hell of a lot less annoying in this regard by mounting it with soft or intr flags, however if the network disappears or hiccups, you WILL lose data (the network is NEVER reliable, in fact the entire model of NFS is arguably wrong to begin with)

marmaduke 7y ago
> the entire model of NFS is arguably wrong to begin with On local networks (everything attached to a single switch) with good hardware, it is reliable, and soft/intr is the worse choice among others. To wit NFS is one of the commonly supported VM storage options (libvirt, VMware, etc).
- yetanotherme 7y ago
  Best of the bad options doesn't make it a good option. It's far from reliable and one of the most common reasons I encounter for deadlocked Linux systems. Well, to be fair, it also hangs a fair share of BSDs and sometimes even a Solaris. If at all possible, I'd suggest avoiding it.
  - marmaduke 7y ago
    What do you propose for a shared file system?
mkesper 7y ago
There is no use in specifying (no)intr as of kernel 2.6.25, it can always be interrupted by sigkill. See e.g. https://access.redhat.com/solutions/157873 https://access.redhat.com/solutions/157873 There are many things "known" about NFS that are legacy.
joosters 7y ago
That's not a problem with NFS, that's a fundamental issue with computers. Things fail. Nothing protects you from losing data, your local log-structured filing systems won't save you either. They'll help you protect an existing state from corruption, but they don't protect you from loss. That new request you just received when a hardware failure occurred? Say goodbye to it, you've no way of ensuring it will make it to storage when the disks have caught fire. Later on, when you've put out the blaze, all that algorithms can do is tell you when things started to get lost.
- quazeekotl 7y ago
  This is a bad excuse for the really flakey nature of nfs, other network filesystems do not have its issues.
  - Volt 7y ago
    Like which ones?
    - throwaway2048 7y ago
      AFS is a good example of a network filesystem that takes properties of the network into account, however its a little weird and not fully compliant with POSIX filesystem semantics. However, it scales like crazy and is very powerful and reliable.
      - deleted 7y ago
        [deleted]
      - IcePic 7y ago
        I ran AFS for very long, it does have issues which perhaps other network fs'es don't even notice. It has issues with clients behind NAT for instance, the callbacks won't work. The limit of files in a dir is less than for local filesystems (or were) so Maildirs with long mail filenames could get into something that feels like "out of inodes but not space" situations. All in all, it was very nice though.

marmaduke 7y ago

> the entire model of NFS is arguably wrong to begin with On local networks (everything attached to a single switch) with good hardware, it is reliable, and soft/intr is the worse choice among others. To wit NFS is one of the commonly supported VM storage options (libvirt, VMware, etc).

yetanotherme 7y ago
Best of the bad options doesn't make it a good option. It's far from reliable and one of the most common reasons I encounter for deadlocked Linux systems. Well, to be fair, it also hangs a fair share of BSDs and sometimes even a Solaris. If at all possible, I'd suggest avoiding it.
- marmaduke 7y ago
  What do you propose for a shared file system?

mkesper 7y ago

There is no use in specifying (no)intr as of kernel 2.6.25, it can always be interrupted by sigkill. See e.g. https://access.redhat.com/solutions/157873 https://access.redhat.com/solutions/157873 There are many things "known" about NFS that are legacy.

joosters 7y ago

That's not a problem with NFS, that's a fundamental issue with computers. Things fail. Nothing protects you from losing data, your local log-structured filing systems won't save you either. They'll help you protect an existing state from corruption, but they don't protect you from loss. That new request you just received when a hardware failure occurred? Say goodbye to it, you've no way of ensuring it will make it to storage when the disks have caught fire. Later on, when you've put out the blaze, all that algorithms can do is tell you when things started to get lost.

quazeekotl 7y ago
This is a bad excuse for the really flakey nature of nfs, other network filesystems do not have its issues.
- Volt 7y ago
  Like which ones?
  - throwaway2048 7y ago
    AFS is a good example of a network filesystem that takes properties of the network into account, however its a little weird and not fully compliant with POSIX filesystem semantics. However, it scales like crazy and is very powerful and reliable.
    - deleted 7y ago
      [deleted]
    - IcePic 7y ago
      I ran AFS for very long, it does have issues which perhaps other network fs'es don't even notice. It has issues with clients behind NAT for instance, the callbacks won't work. The limit of files in a dir is less than for local filesystems (or were) so Maildirs with long mail filenames could get into something that feels like "out of inodes but not space" situations. All in all, it was very nice though.