# [ZFS]  Replacing discs in a pool with different type/vendor



## zeebee (May 8, 2013)

Dear FreeBSD community,

I'm an all-by-myself, self-taught sysadmin for two years now, running two FreeBSD file servers. Google and a forum search didn't reveal a conclusive answer to me.

My question regards a data-only RAIDZ-2 pool running on bare/whole discs (ZFS Version 28 on FreeBSD 8.2-STABLE). Drives in the pool have begun showing failures and we need to prepare for upcoming disk failures by buying replacement drives.

Can we replace the disks in question with disks of another type and/or vendor, given that they have the same capacity (2TB in current setup) as their predecessors?

Bonus Question: Would this also be possible on a root pool residing on a slice (besides the boot-fs and swap partition)?

Thanks for reading and answering.


----------



## SirDice (May 8, 2013)

zeebee said:
			
		

> Can we replace the disks in question with disks of another type and/or vendor, given that they have the same capacity (2TB in current setup) as their predecessors?


I don't think that will pose any problems. One thing I did think of was block size. Some drives have 512 others 4096. Mixing those up may have a serious impact on performance.


----------



## zeebee (May 8, 2013)

Thank you,

How could I determine the block size of the currently deployed drives?


----------



## SirDice (May 8, 2013)

You could have a look with diskinfo(8). Although some drives "lie" to the OS about their block sizes, not sure how diskinfo(8) copes with that. You may need to look at the original specifications of the drive.


----------



## kpa (May 8, 2013)

diskinfo(8) has no special knowledge of the disks, it just reports what the the disk driver was given by the disks.


----------



## zeebee (May 8, 2013)

*How to obtain block size then?*

Could the blocksize be determined from the disk's documentation?

From your experience, is the information from `diskinfo` usually in correct?


----------



## kpa (May 8, 2013)

It's almost always wrong with the newer disks with 4k sector size. The trouble with those is that if they reported the correct sector size they would be unusable on large part of computers, at least for booting because BIOSes don't have support for booting from 4k sector disks.


----------



## wblock@ (May 8, 2013)

The disk specifications may show the true block size, or mention "Advanced Format", a euphemism for 4K blocks.

Use `gpart list ada0`:

```
...
Consumers:
1. Name: ada0
   Mediasize: 256060514304 (238G)
   Sectorsize: 512
   [color="Red"]Stripesize: 4096[/color]
   Stripeoffset: 0
   Mode: r3w3e9
```

Stripesize is the true block size.


----------



## zeebee (May 8, 2013)

*is stripesize in geom equal to stripesize in diskinfo?*

Hello @WBlock,

Thanks for the clarification.

Since I use bare disks without partitions `gpart` only yields a "no such geom" error.

However the before mentioned `diskinfo -v` also gives a stripe size:

```
/dev/ada2
        512             # sectorsize
        2000398934016   # mediasize in bytes (1.8T)
        3907029168      # mediasize in sectors
[B]        4096            # stripesize[/B]
        0               # stripeoffset
        3876021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
```

Is this equivalent to the stripe size provided by gpart(8)?


----------



## wblock@ (May 8, 2013)

For bare disks, I'd think it would be the same.  But I have not checked that.


----------

