Richard, > Ross wrote: >> The problem is they might publish these numbers, but we really have >> no way of controlling what number manufacturers will choose to use >> in the future. >> >> If for some reason future 500GB drives all turn out to be slightly >> smaller than the current ones you're going to be stuck. Reserving >> 1-2% of space in exchange for greater flexibility in replacing >> drives sounds like a good idea to me. As others have said, RAID >> controllers have been doing this for long enough that even the very >> basic models do it now, and I don't understand why such simple >> features like this would be left out of ZFS. >> >> > > I have added the following text to the best practices guide: > > * When a vdev is replaced, the size of the replacements vdev, measured > by usable > sectors, must be the same or greater than the vdev being replaced. > This > can be > confusing when whole disks are used because different models of > disks may > provide a different number of usable sectors. For example, if a pool > was > created > with a "500 GByte" drive and you need to replace it with another "500 > GByte" > drive, then you may not be able to do so if the drives are not of the > same make, > model, and firmware revision. Consider planning ahead and reserving > some > space > by creating a slice which is smaller than the whole disk instead of > the > whole disk.
Creating a slice, instead of using the whole disk, will cause ZFS to not enable write-caching on the underlying device. - Jim > > >> Fair enough, for high end enterprise kit where you want to squeeze >> every byte out of the system (and know you'll be buying Sun >> drives), you might not want this, but it would have been trivial to >> turn this off for kit like that. It's certainly a lot easier to >> expand a pool than shrink it! >> > > Actually, enterprise customers do not ever want to squeeze every > byte, they > would rather have enough margin to avoid such issues entirely. This > is what > I was referring to earlier in this thread wrt planning. > -- richard > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
