A Debian GNU/Hurd snapshot

Posted Jun 20, 2013 20:49 UTC (Thu) by zlynx (guest, #2285)
In reply to: A Debian GNU/Hurd snapshot by simlo
Parent article: A Debian GNU/Hurd snapshot

Aren't you handling errors coming from local files? Which might be on a SAN anyway.

A Debian GNU/Hurd snapshot

Posted Jun 21, 2013 22:35 UTC (Fri) by simlo (guest, #10866) [Link] (4 responses)

The delays are still in ms with a SAN. With an ftp "filesystem" is is in seconds. Many programs will simply freeze when such "filesystems" make hickups.

A Debian GNU/Hurd snapshot

Posted Jun 22, 2013 2:03 UTC (Sat) by zlynx (guest, #2285) [Link] (3 responses)

The delays is in ms IF your SAN is working properly.

A SAN is exactly as vulnerable to problems as any LAN. It is the same hardware after all.

A Debian GNU/Hurd snapshot

Posted Jun 26, 2013 20:14 UTC (Wed) by bronson (subscriber, #4806) [Link] (2 responses)

SAN is engineered to look like local storage. If there's a one second delay, that will be hunted down and fixed (or fire your IT guy). Definitely not true of FTP.

Just because both go over the same wire, that doesn't mean that they'll have the same behavior.

Having lived through the late-90s latency-riddled nightmare of CORBA/xRPC/SOAP leaky abstractions, I gotta agree with simlo: existing apps will probably not handle these filesystem objects very well.

A Debian GNU/Hurd snapshot

Posted Jun 26, 2013 21:20 UTC (Wed) by zlynx (guest, #2285) [Link] (1 responses)

SAN used to look like local storage when that meant hard drives.

Now SAN is back looking like remote network storage when its almost 100x slower than PCIe flash.

Even when your remote storage is flash the SAN sticks almost a whole extra millisecond in there on each request.

But anyway. My original point was I think that applications ought to be just as careful with their writes to local disk as they are with writes to remote network servers. Not that they are. But they ought to consider what happens if the local disk refuses to accept a write, or if the local disk takes multiple seconds to return the next data block.

Because the local disk very well may do that. If the app is relying on a 10ms fsync return in order to remain responsive, that app is not going to be responsive. And if it relies on the disk always accepting a write without errors, its going to lose data eventually.

A Debian GNU/Hurd snapshot

Posted Jun 27, 2013 2:03 UTC (Thu) by bronson (subscriber, #4806) [Link]

Ideally, yes, an application should check every local write. It should also check every malloc/free/read/stat/etc/etc/etc. And it shouldn't ever block.

Practically, this sort application is very difficult to write and maintain. That's why most (essentially all?) nontrivial apps tend to react poorly when fooled into thinking a distant SFTP site is a local disk.

Will this change? Dunno! It's just the way things exist today.