Unix has a slightly odd way of handling file access permissions, inthat they're only checked when a file is opened, not every time thatyou attempt to do something with the file handle. While the choice isdefensible, in many ways checking permissions on access would be moreconvenient, since it would enable things like immediately revokingaccess to files, and very few programs actually care about this.

(And these days, it would fit better into network filesystems, manyof which operate this way anyways.)

Given modern email , one may sensibly ask what the roleof various sorts of autoresponders and other 'do things by email' thingsare. The simple answer is that they have no role; they cannot send emailto people who have not asked for it, plus pragmatically, most of theemail that they get will have forged sender information and be invalid.

Well, sort of, because the statement of the limitations also shows howyou can get around them. There are two general approaches.

First, you can simply

Suppose that you have a ZFS pool with various filesystems, and whilethe filesystems have data in them, you're just using the pool as acontainer; the top level pool filesystem has no data itself. In thissituation, a df of the pool on the Solaris host will show somethinglike:

Filesystem  size  used  availtank01      300G   20K    40G

Translated, we can see that the pool itself is 300G, the pool's toplevel filesystem has nothing

The easiest way to dig yourself out of the hole created by the RAIDgrowth gotcha is probably to use a live/rescue CD.But let us suppose that you don't have one handy, which was the casefor me yesterday. Further let us suppose that you have /boot as a separate filesystem , not as part of the rootfilesystem (if this is not the case, you absolutely need a rescue CD;sorry).

The basic goal is to rebuild a version of your current initrd that has

Suppose that you have a system with a mirrored root filesystem and,for some reason , you need to boot it withoutthe mirror being available. At one level, this is very easy; all youneed to do is to find the partition of one of the mirrors and specifyit as the filesystem root device on the kernel command line with' root=/dev/sdXX '.

This works because while software RAID embeds its own metadata in thepartitions, it puts the metadata at the end of the partition,

Suppose that you have a fully mirrored system and you want to expandyour available space by migrating to a pair of larger hard drives. Theobvious way to do this is fairly straightforward, assuming that youcan connect all of your drives at once: partition the new drives (withlarger partitions for at least some of your software RAID devices), addthe new partitions to the appropriate MD device, let things resync, andthen detach the old disks (and eventually physically remove them).

(Hopefully the obvious way

I was asked today if I thought that a disk-based backup system could do restores faster than a tape-based system. Mybest answer was a 'maybe', because it really depends on what thelimiting factor is in your restores. Let's look at all of the thingsthat have to happen in a restore:

1. you find and load the tape into the tape drive or tape library,if it's not already there.
2. if you have a tape library, it loads the tape into the

One of the slightly subtle advantages of disk-based backup systems over tape-based backup systems is thatcapacity expansion is much easier; all you have to do is start usingbigger disks. Since SATA is SATA, you don't need to replace yourenclosure, and it is relatively easy to have multiple generations ofdisks with different capacities cycling through your system.

Contrast this with tape backups. To upgrade to higher capacity tapes,you have to not just buy the tapes, you generally have to buy an entire

Our solution to the tape backup cost problem hasbeen to move to a disk-based backup system. The most important enablingthing for this is that when we built the latest version of our iSCSIbackends , we discovered that we could geta pretty nice 12-bay ESATA-based enclosure for reasonably cheap, and iteven has 'tray-less' drive bays that could be hotswapped.

(Tray-less drive bays are drive bays where you simply slide the baredrives in and out; you do not