One of the things that the Samba people say in response to certainproblem reports is that you should not useSamba on NFS-mounted filesystems. This is impractical advice in manyproduction environments, and I will tell you why: namespaces. Or lessabstractly, making it so that users do not have to know what fileservertheir files come from.

We are not atypical as midsized environments go, and right now we havefour fileservers and around two hundred filesystems distributed betweenthose fileservers. We do not particularly want users to

We recently upgraded our Samba servers from an old version of Ubuntu andSamba to a new version of both. When we did this, we found that WindowsXP machines running Office 2003 stopped being able to save documentsin Office 2003 formats. Attempted saves would fail with a more or lessgeneric error, and opening documents would stall for a while and thenopen them read only.

(Yes, it really is this specific. For example, Office 2003 can savethe same

Unix has generally had decent APIs, but every so often Unix people havebeen a bit too concerned with minimalism and storing data as efficientlyas possible. Several times this has invited in string-related APIs thatpractically beg for code to make mistakes, because of how they specifystring termination.

Here is an abstracted example. Consider an API where you use thefollowing structure:

struct dirent {    uint16_t  ino;    char      name[14];}

You will notice that there is nothing explicit to tell

In a conventional RAID system with a RAID array that's made up frommultiple mirrors, mirror resynchronization is a single-mirror affair.Other mirrors in the array are not affected. This is not how ZFS works.

One of the consequences of ZFS scrubs and resilvers being nonlinear is that resilvers do not neatly confine theiractivity to only the disks of the vdev being resilvered. Instead, ZFSmay need to traverse data structures that live in other vdevs in orderto find out what data is live on the resilvering vdev

Suppose that you run production machines, where you don't want to haveto reboot things without a bunch of advance planning (or a seriousemergency). One of the things you want to do on such a system is blockkernel updates. On dpkg-based systems, this is called holding a package.

(One way to do it, the one I use, is ' echo pkgname hold | dpkg--set-selections '. ' dpkg --get-selections | fgrep hold ' can then

This is in part a war story.

We've written our own system to handle deploying spares on our ZFSfileservers . One of the decisionswe made was how much activity to have the system start at once,because we already knew that trying to resilver too many mirrorsat once killed performance for everyone. What we decided was thatwe only wanted one resilver to happen at once and further that wewould abort any ZFS scrubs that were in progress if we needed toactivate a spare, because getting a mirror back

Here is a tough trick question: which is better, a mailbox format whereall the messages are just concatenated together (eg, traditional Unixmbox) or a mailbox format where everything is concatenated togetherbut you have an index of the starting byte offsets of every message'sheaders and body (an indexed mbox format)?

(Assume that there is no overhead for maintaining the index.)

Some years ago, I would have confidently told you that the indexed mboxformat was clearly better, and it was obviously more

A commentator on this entry asked what soundslike a good question: why don't I have Grub2 boot the older kernel that Iwant to use, instead of removing the newer one?

The problem is that it's not a robust solution. The first and largestissue is that what I really want to do is enforce a negative ('neverboot this specific kernel'), but the only tool Grub gives me is apositive one ('boot this specific kernel'). There are a

The other day I was reading A Tale of Two Standards ,where Jeremy Allison mentions in passing:

Interestingly enough the SUS doesn't cover such things as the graphical user interface (GUI's)elements, as the history of Unix as primarily a server operatingsystem meant that GUI's were never given the importance needed forUnix to become a desktop system.

I don't think that this is the real reason that there is no POSIX orequivalent standard for Unix graphical user interfaces. Because I am a