What *is* "error 19" ?

[MMacD]

The other day I had a disc go bad in one of my mirrors. I'm now trying to format and integrate its replacement.

But if I add the disc to the system, I can't boot. FreeBSD gets lost and becomes unable to figure out where root is or how to mount it, even though it's (of course!) on the same physical disk and partition it's been since I integrated the machine. If I remove the disc again, the system boots fine.

Which suggests to me that device identifiers are invented during boot rather than conserved across changes such as, oh, adding another disc.

So what actually is error 19 where FreeBSD is concerned? I googled for it, but got nothing.

And, perhaps more to the point, is there anything I can do to keep the system from becoming bewildered and non-functional when I connect up a new drive?

 

[wblock@]

See errno(2). Error 19 is ENODEV, "operation not supported by device", but what it usually means in the loader is "device not found".

The way to avoid this is to not use static device names like /dev/ada0, but labels. Labels can be assigned to a particular device and stay with that device. Device numbers are often dynamic and depend on which devices are connected.

As a poor temporary workaround, it is usually possible to figure out the order in which SATA ports are detected and make sure the boot device is attached to the first. Long-term, use labels, preferably GPT labels which are convenient and do not interfere with partitioning.

 

[MMacD]

Ah, thanks for the pointer to errno(2). Pity the search didn't find it.

Labels definitely sound like the device-identifiers that should have been used from the first. I think I'll boot from a cd, add labels, and edit /etc/fstab before I try again to integrate that replacement disc. Does ZFS get bothered or confused by GPT labels?

Is it possible to GPT-label a Windows NTFS MBR disc, or would that get Windows/NTFS upset?

 

[SirDice]

Does ZFS get bothered or confused by GPT labels?

No, it doesn't even care about the order. They don't even need to be connected to the same controller. It uses its own identification to find the disks, the order and the configuration.

Is it possible to GPT-label a Windows NTFS MBR disc

You can't use GPT labels on MBR. GPT and MBR are two different partitioning schemes. That said, you can use labels with MBR partitions/slices. Windows shouldn't have a problem with it.

 

[MMacD]

The docs give as an example labeling the boot-drive partitions using glabel label to generate permanent but generic labels. I was going to use tunefs to create ufs-specific labels. Is there an advantage to use generic vs fs-specific labels (or vice-versa)?
(I thought I'd answered my own question, but there are other drives besides the boot drive so the question still applies to them)

Ah, cheese, I'm just discovering more questions the closer I get. How about smartd? Does it understand labels? If labels are just another layer, and the system still creates the original-flavor identifiers underneath them, I could imagine smartd using the original ones and me having a dreadful time trying to map.

 

[SirDice]

I've used both and there's no inherent benefit to one or the other. But you can't always use the tunefs(8) labels (when it's not UFS for example), in which case glabel(8) works just as good.

 

[wblock@]

The glabel(8) system automatically uses volume labels from a bunch of different filesystems, see the man page. The problem with using actual generic labels is that they create metadata at the end of the volume or device, and if you don't access that device through the label, that metadata can be overwritten. GPT labels are in the partition information and conveniently out of the way.

I have not tried smartctl with labels, but it ought to work. I think. The only way to do that would be a generic label at the end of a disk, and then it won't be the bare device, but the device minus one block for metadata.

 

[MMacD]

I've used both and there's no inherent benefit to one or the other. But you can't always use the tunefs(8) labels (when it's not UFS for example), in which case glabel(8) works just as good.

Thanks -- that's what I'll use, then.

I've been trying to puzzle out how to label the MBR NTFS disks so that I can mount them without using the mayfly device names. Calling glabel list only shows me Windows's NTFS slices on the (dual-)boot disc. I thought at first that was because the Win7 label ("C_W7 boot") counts as being a glabel label. Yet I have W7 labels on the other NTFS discs too...but it's not listing them. So I don't know how to interpret that.

 

[MMacD]

The problem with using actual generic labels is that they create metadata at the end of the volume or device, and if you don't access that device through the label, that metadata can be overwritten. GPT labels are in the partition information and conveniently out of the way.

I may have lost the thread here. If there's a label, why would anyone not use it to access the device? Or am I just plain confused? EDIT Yes, I am just plain confused: I thought glabel labels are GPT labels. Not so?

I have not tried smartctl with labels, but it ought to work. I think. The only way to do that would be a generic label at the end of a disk, and then it won't be the bare device, but the device minus one block for metadata.

hmmm...perhaps the prudent thing to do, then, would be to apply a label to a scratch disc and see what smartd thinks of it?

Just for the sake of my peace of mind: adding a label doesn't bother any of the data on the disc, right?

 

[ralphbsz]

I have not tried smartctl with labels, but it ought to work. I think. The only way to do that would be a generic label at the end of a disk, and then it won't be the bare device, but the device minus one block for metadata.

It doesn't work, at least not easily. I use GPT labels for all my disks (I think there are 5 attached to my server), and that's a great thing, because the external eSATA disk is sometimes not present while booting, so all the /dev/ada names shift over by one. The only thing I haven't gotten to work yet is smartctl and smartd. They refuse to work on partitions, and their arguments (on the command line or in the configuration file) need to be whole disks. And labels apply to partitions, not whole disks. I gave up after half hour of tinkering with it, maybe there is a way to do it.

 

[wblock@]

This is a GEOM system. If there are volume/filesystem labels, it will show them in /dev. There are numerous versions of NTFS, maybe some put the volume name information elsewhere and the label system doesn't see it.

Generic labels are assigned manually. Persistent ones are written to the last block on the device or partition. Then you use the label name to access the device or partition.

For example, consider the second partition in an MBR system. The device name is ada0s2. Create a generic label on it: glabel label snert /dev/ada0s2. Now there is a new device called /dev/label/snert. The size is one block less than the original ada0s2, because that last block is used for metadata. When you format or use it, use /dev/label/snert. Some people think the label is just added on magically somewhere, and continue to use ada0s2. That can end up overwriting the metadata.

Because of the metadata written to the last block, a generic label is not useful for an existing partition or filesystem. Maybe there is nothing there, but it was created expecting that block to be available. Don't try to add a generic label to a filesystem or disk with data on it.

With GPT labels, the label goes in the partition table. It does not take any extra space on the disk, and you can write them at any time without worrying about them overwriting something. The device or partition remains the same size, too. So GPT labels are very convenient.

 

[MMacD]

... Generic labels are assigned manually. Persistent ones are written to the last block on the device or partition. Then you use the label name to access the device or partition. ...

Because of the metadata written to the last block, a generic label is not useful for an existing partition or filesystem. Maybe there is nothing there, but it was created expecting that block to be available. Don't try to add a generic label to a filesystem or disk with data on it.

With GPT labels, the label goes in the partition table. It does not take any extra space on the disk, and you can write them at any time without worrying about them overwriting something. The device or partition remains the same size, too. So GPT labels are very convenient.

Thank you! As always, that's an exceptionally clear explanation. I wondered why the last block would be vulnerable to overwriting since I supposed glabel label would mark its block "occupied" in the allocation table. Isn't the problem the same even when glabel labeling a freshly-formatted disc/partition? Somehow it has to say "this is a one-block file, don't mess with it" or similar, doesn't it?

I did GPT-label the boot drive in my server-of-all work yesterday, and will fix up /etc/fstab today. It's clearly going to be a big convenience not having to decode the mayfly identifiers when adding or removing a device.

Now I want to zero out the failed drive in prep for its warranty exchange, but I'll start a new thread for that question.

 

[wblock@]

I wondered why the last block would be vulnerable to overwriting since I supposed glabel label would mark its block "occupied" in the allocation table. Isn't the problem the same even when glabel labeling a freshly-formatted disc/partition? Somehow it has to say "this is a one-block file, don't mess with it" or similar, doesn't it?

There is no allocation table on a partition, that's a filesystem-level feature. The label device, /dev/label/snert from the example above, is one block smaller than the partition. Anything that writes to /dev/label/snert is safe and will run out of blocks before overwriting the metadata. Just realize that there is no such protection for writing to the underlying partition, /dev/ada0s2.