Re: Sticks with not lights

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 07, 2018 at 08:08:41PM -0500, Fulko Hew wrote:
> old brain remembers ... sync; sync; sync;

Yep, that was the mantra.

> Supposedly,
> #1 for the data blocks,
> #2 to ensure the updated inodes got written,
> #3 to ensure that superblock updates got written (if necessary).

Well, that wasn't so.  I was doing Unix internals at Bell Labs in 1980.
Sync flushed all pending disk I/O operations for the entire kernel
...that's all processes and *all users* on a multi-user machine.
The idea was apparently that multiple "syncs" would assure flushing
operations that would get submitted; even then it was a bit of apocrypha.

However, the early days *were* interesting; BTL was pushing Unix hard by
1980, especially for the 5ESS project, and more people than had ever been 
using a Unix system concurrently were on the development systems.

One week started out badly for us; for some reason everyone was
experiencing *incredibly* poor performance.  We figured out that we were
all on the same server, but the poor guys in the data center couldn't see
anything wrong; it was just, suddenly, and inexplicably ***slow***.

I was chatting with a new hire who'd started that morning, and he proudly
showed me a vi macro he'd written to "guarantee that he never lost data".
Really?  Let's see...hmm...every command issued was intercepted...AND
CALLED SYNC.  On a machine hosting a boatload of other users.  He was
calling sync for every single editor command he typed.

Cluebat applied, macro removed, life returned to normal.

(And no, I don't know when they stopped letting a single user do that to
the whole system, and lost access to Unix source when I left the Labs Way
Back When, but they *must* have, right?  And no, I've not cared enough to
go see how Linux does it.)

Cheers,
--
	Dave Ihnat
	dihnat@xxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux