I spent a chunk of today checking out the performance of 10Gnetworking on what we hope will be our new iSSCSI backend hardware and in the process I made aninteresting discovery: at 10G speeds, the size of your program's networkbuffers can matter. In fact it can matter a lot.

I'm used to a network environment where it doesn't really matter howmuch you write() to the network at once as long as it's not stupidlysmall. Going much

Basically all modern disks (SAS, SATA, etc, it doesn't matter) havewrite caches. I think that most disks these days default to having themon, even in the 'enterprise' space, since enterprise OSes have generallybeen dealing with disk write caches for some time and so are safe in theface of them.

(In the old days when write caches were just starting to appear, thestereotype was that consumer drives defaulted to enabling it andenterprise drives to disabling it.)

Generally,

Suppose, not entirely hypothetically, that you want to test how wellsome new storage hardware and disks stand up to a lot of write cacheflush operations ( eg ); you don'tcare about high level filesystem operations, you just want to hammer onthe disks and the disk interconnects.

I will cut to the chase: the simplest and most direct way of doingthis on Linux is to call fsync() on a (or the) disk block device.This appears to always generate a SYNCHRONIZE_CACHE

There is a meme running around the Internet that if you don't pay forthe services you use, you're a sheep. The problem with this is thatwe have plenty of demonstrations that even paying for services is notnecessarily good enough to insure you won't be turned into a sheep.

My personal demonstration of this is Flickr. I've paid for a Flickr Promembership (and felt it was worth it) for years, but then Yahoo changedthe account structure this summer. Flickr'

We're in the process of renewing the hardware for our fileserverinfrastructure and we've just got in theevaluation unit for what we hope will be the new backend hardware. Oneimportant part of evaluating it will be assessing how it does disk IO,so this entry is me thinking out loud about a high level view of whatI want to test there.

In general we need to find out two things: how well does the hardwareperform and whether it explodes under high load or other abnormalconditions. Since

If you hang around distributed filesystem developers, you may hear themsay grumpy things about NFS's handling of concurrent writes and writesin general. If you're an outsider this can be a little bit opaque.I didn't fully remember the details until I was reminded about themrecently so in my usual tradition I am going to write down the coreproblem. To start with I should say that the core problem is with NFSthe protocol, not any particular implementation.

Suppose that you have two processes,

One of the things that's been in the 'devops' ambient lately is Docker.The vague and probably partially inaccurate things I've heard about itand the general idea of 'containers' have inspired some thoughts, whichI will summarize by saying that I'm all for the abstract idea.

The thing is, I don't really want to be managing machines. It's a painin the rear. Nor do I really want to have virtualization because thatactually means managing more machines (

Here is a lesson that only sank into my head very recently: you shouldnever allow user contributed content to break your layout . Or, really,any outside content; by this I mean things that show up basicallyoutside of your control and get dropped into your pages.

You might wonder how on earth you stumble into this problem in the firstplace. In my case what happened here on Wandering Thoughts was comments with preformatted text that had lines that were too longfor the width of your browser window. This has

ZFS keeps lots of copies of a pool's uberblock ;on a standard pool on disks with 512 byte sectors, you will haveat least 127 old uberblocks. In an emergency ZFS will let you rollback to a previous uberblock . So clearly you havea lot of possibilities for rollback, right?Actually, no. You have far less than you might think . The rootproblem is a misconception about the rate of change in pool andfilesystem metadata.

In a conventional filesystem implementation, top