comment at the bottom...

Tim wrote:
> On Sun, Jan 18, 2009 at 1:56 PM, Eric D. Mudama 
> <edmud...@bounceswoosh.org <mailto:edmud...@bounceswoosh.org>> wrote:
> 
>     On Sun, Jan 18 at 13:43, Tim wrote:
> 
>          You look at the size of the drive and you take a set percentage
>         off...  If
>          it's a "LUN" and it's so far off it still can't be added with the
>          percentage that works across the board for EVERYTHING ELSE, you
>         change the
>          size of the LUN at the storage array or adapter.
> 
>          I know it's fun to pretend this is rocket science and
>         impossible, but the
>          fact remains the rest of the industry has managed to make it
>         work.  I have
>          a REAL tough time believing that Sun and/or zfs is so deficient
>         it's an
>          insurmountable obstacle for them.
> 
> 
>     If, instead of having ZFS manage these differences, a user simply
>     created slices that were, say, 98% as big as the average number of
>     sectors in a XXX GB drive... would ZFS enable write cache on that
>     device or not?
> 
>     I thought I'd read that ZFS didn't use write cache on slices because
>     it couldn't guarantee that the other slices were used in a
>     write-cache-safe fashion, would that apply to cases where no other
>     slices were allocated?
> 
> 
> It will disable it by default, but you can manually re-enable it.  
> That's not so much the point though.  ZFS is supposed to be 
> filesystem/volume manager all-in-one.  When I have to start going 
> through format every time I add a drive, it's a non-starter, not to 
> mention it's a kludge.

DIY.  Personally, I'd be more upset if ZFS reserved any sectors
for "some potential swap I might want to do later, but may never
need to do."  If you want to reserve some space for swappage, DIY.

As others have noted, this is not a problem for systems vendors
because we try, and usually succeed, at ensuring that our multiple
sources of disk drives are compatible such that we can swap one
for another.
  -- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to