Trading off safety and performance in the kernel

Posted May 13, 2015 16:53 UTC (Wed) by pizza (subscriber, #46)
In reply to: Trading off safety and performance in the kernel by zblaxell
Parent article: Trading off safety and performance in the kernel

> A class 4 SD/MMC card inside a laptop that has 16GB of RAM: one hour, four minutes.

Come now, this use case is rather facetious.

Or are you seriously saying that someone who will configure a system with 16GB of RAM (presumably for performance) will be so cheap as to use a class 4 SD card for backing storage? (a 16GB UHS-1 card can be easily found for $11!)

> A network filesystem that is broken because the network interface is down due to the suspend event: forever.

Heh. Given that I literally haven't had this happen in literally over a decade, this makes me wonder what broken-ass distro you're using that included such screwed up suspend scripts. (And for the record, I do this multiple times a day with both CIFS and NFS mounts)

Then again, you did say that you replaced your distro's suspend/resume scripts with your own stuff, so I suppose you only have yourself to blame.

> The latter case is the reason why I've not had that SYS_sync() line in my kernels for almost 10 years.

Good for you; you worked around your own mistakes...Do you want a cookie or something?

Trading off safety and performance in the kernel

Posted May 13, 2015 19:29 UTC (Wed) by zblaxell (subscriber, #26385) [Link] (1 responses)

> Or are you seriously saying that someone who will configure a system with 16GB of RAM (presumably for performance) will be so cheap as to use a class 4 SD card for backing storage?

I'm saying that someone on a client site will use whatever horrible SD card they are given to transfer a crapton of data, then unexpectedly have to complete a suspend/resume cycle because they need to pack up the laptop so they can move to another building for a meeting with someone important who is only available now--not in an hour, when it's finally possible to remove the SD card without data loss.

This is a common case for me. I've modified both kernel and userspace to mitigate the problem, but anyone using default Linux distro and kernel behavior is screwed.

> Heh. Given that I literally haven't had this happen in literally over a decade, this makes me wonder what broken-ass distro you're using that included such screwed up suspend scripts. (And for the record, I do this multiple times a day with both CIFS and NFS mounts)

Debian gave a choice of two bad behaviors: fail to suspend, or forcibly umount filesystems to avoid suspend blocking on sync() (or read, or any other filesystem operation for that matter).

What I want is for the filesystem to stay mounted. If the suspend/resume is for a short walk to another building, there is no need to disrupt userspace with a umount. Any reads or writes in progress can be completed after resume using the network filesystem client's existing code for dealing with ordinary network interruptions. There should be no blocking code paths on suspend for such filesystems *at all*.

Trading off safety and performance in the kernel

Posted May 14, 2015 16:06 UTC (Thu) by marcH (subscriber, #57642) [Link]

> If the suspend/resume is for a short walk to another building,

Is there a user interface to express the difference between short walks versus long commute home + change of network?

Among the many things NFS was really not designed for, mobility must be very near the top of the list.

All traditional network filesystems suck and are on their way to the dustbin of history since they ignored Fallacy of Distributed Computing number 1 (and a few others). NFS just sucks more.