WD100EMAZ strange noise

[msg7086]

You are very welcome. Glad to see your problem is solved.

I'm no expert on ZFS, but I guess zfs import -d will actually write the new device info into its meta data. It's not like MD or LVM where you can scan the drives and reassemble everything magically. Inside the meta data there are paths to the devices, so they have to be accurate when the array is imported.

I was taught to always use drive id to create zfs volumes, so I never had to worry about sdX problem.

 

[BLinux]

As an aside... does ZFS not write its metadata to the drives then...? Any number of things can transpire to change /dev/sdX to /dev/sdY and I didn't think anything relied on persistent device names any more.

If that's the case, doesn't that also mean that if you use by-path IDs the pool will fail to import if you move to a different HBA/different PCI slot?

yes, metadata is on disk, so any change like /dev/sdX to /dev/sdY is not a problem for the *data* disks. I believe this is not true for L2ARC or SLOG device, so those must reference a consistent path like /dev/disk/by-id or similar.

And because there is metadata on disk, moving to different hardware location is not a problem to import the pool. However, SLOG device *might* be a problem if referenced by /dev/disk/by-path and that changes.

 

[BLinux]

You are very welcome. Glad to see your problem is solved.

I'm no expert on ZFS, but I guess zfs import -d will actually write the new device info into its meta data. It's not like MD or LVM where you can scan the drives and reassemble everything magically. Inside the meta data there are paths to the devices, so they have to be accurate when the array is imported.

I was taught to always use drive id to create zfs volumes, so I never had to worry about sdX problem.

the metadata on disk will allow you to re-assemble the pool even if the drive "path" changes, but that path is not stored in metadata as far as I know. when you successfully import a pool, the path names are recorded in a cache file; which is re-used when you re-import that same pool. that's where the path names are stored, not in the meta data; i believe.

You can move all those disks to another machine, on a brand new install, that doesn't have the cache file. You can then do an "zpool import -a" and it will scan all disks for the metadata and try to find all the components to an existing pool and import it. If you have metadata that doesn't match, for example, 2 different pools both named "tank", you can still import it by uuid number.

 

[madbrain]

yes, metadata is on disk, so any change like /dev/sdX to /dev/sdY is not a problem for the *data* disks. I believe this is not true for L2ARC or SLOG device, so those must reference a consistent path like /dev/disk/by-id or similar.

It was definitely a problem for me. I only have data disks, no L2ARC or SLOG device. The /dev/sdX device names were seemingly changing at every reboot, without any hardware change. This is what was causing the automatic import of my volume to fail. I think the cache file on my root file system may have been storing the old device names, and tried to restore the pool from the same device names, but it failed. But when I did manual import with the array name, it succeeded.