As I mentioned in my entry on the effects of losing a SLOG device , our initial plan (or really idea) for SLOGsin our new fileservers was to use a mirroredpair for each pool that we gave a SLOG to, split between iSCSIbackends as usual. This is clearly the most resilient choice for aSLOG setup, assuming that you have SSDs with supercaps; it wouldtake a really unusual series of events to lose any committed datain the pool.

On ZFS mailing lists that I've read,

As I mentioned on Twitter , I'verecently started seeing some amount of comment spam attempts fromIPs that are more or less explicitly labeled as Tor exit nodes.While I haven't paid exhaustive attention to comment spam sourcesover time, to the best of my awareness this is relatively newbehavior on the part of my comment spammers. To date not very manycomment spam attempts have been made from Tor IPs and other sourcesstill dominate.

Since none of the comment spam attempts have succeeded, I face notemptation

Back when we planned out our new fileservers ,our plan for any ZIL SLOG devices we'd maybe eventually put on hotpools was to use mirrored SLOG SSDs, just as we use mirrored disksfor the main data storage. At the time when I put together theseplans, my general impression was that losing your SLOG was fatalfor your pool; of course that meant we had to mirror them to avoida single device failure destroying a pool. Since then I've learnedmore about the effects of ZIL SLOG

Me on Twitter :

Youtube's autoplay behavior makes me so angry. No no no aughwrong. What a way to rudely demand attention.

The single thing I hate the most about Youtube is that its videosstart playing the moment you open one. On the one hand I can kindof see why Youtube does this; I'm sure they have plenty of userexperience studies that tell them that without autoplay peopledislike having to do an extra step to get what they came to Youtubefor and that a certain

Allegedly (and I say this because I have not looked for primary sources)some existing Linux filesystems are adding metadata checksums and thenexcusing their lack of data checksums by saying that if applicationscare about data integrity the application will do the checksummingitself. Having metadata checksums is better than having nothing and adding data checksums to existing filesystems is likely difficult , but this does not excuse their viewsabout who should do what with checksums.

There are at least two reasons why filesystems should do datachecksums. The first is that data

The other day I ran down why ZFS is your only real choice on Linuxif you need an advanced filesystem .Well, it's not just Linux. I don't know enough about the landscapeof filesystems on other Unixes to confidently say it's your onlychoice on non-Linux Unixes, but I do think it is by far your bestchoice for this job .

Let's start with the first and biggest reason: ZFS works and hasfor years . At this point ZFS has been running

Suppose, not entirely hypothetically, that you have three machines:a laptop or desktop, some general access login servers thatyou do most of your sysadmin work from, and some fileservers that the login server mounts allsorts of things from. It's convenient to have passwordless ssh accessfrom the login server where I work to the fileservers so that I cando things like conveniently run a command on several of them atonce , but at the same time there are some security andconvenience issues.

If I use an

If you are designing integrity checksums into a new filesystem or trying to adding them to an existing one, thereare some broad choices you have to make about them. These choices willdetermine both how easy it is to add checksums (especially to existingfilesystems) and also how much good your checksums do. Unfortunatelythese two things pull in the opposite direction from each other.

Two big choices are: do you have checksums for just filesystem metadataor both data and metadata, and are your checksums 'internal' (stored

Yesterday I wrote about what I consider advanced filesystems arein general , namely filesystemswith the minimum feature of checksums so you know when your datahas been damaged and ideally with some ability to use redundancyto repair from damage. As far as I know, today on Linux there areonly two filesystems that are advanced in this way: btrfs and ZFS, via ZFSon Linux .

(If you don't care about disk checksums, you have lots of choiceamong perfectly good filesystems. I would just run ext4