But presumably it would be possible to use additional columns for future
writes?
I guess that could be made to work, but then the data on the disk becomes
much (much much) more difficult to interpret because you have some rows which
are effectively one width and others which are another
I guess that could be made to work, but then the data on
the disk becomes much (much much) more difficult to
interpret because you have some rows which are effectively
one width and others which are another (ad infinitum).
How do rows come into it? I was just assuming that each
Maybe this is a dumb question, but I've never written a
filesystem is there a fundamental reason why you cannot have
some files mirrored, with others as raidz, and others with no
resilience? This would allow a pool to initially exist on one
disk, then gracefully change between different
On Thu, Jul 13, 2006 at 09:44:18AM -0500, Al Hopper wrote:
On Thu, 13 Jul 2006, David Dyer-Bennet wrote:
Adam Leventhal [EMAIL PROTECTED] writes:
I'm not sure I even agree with the notion that this is a real
problem (and if it is, I don't think is easily solved). Stripe
widths are
Infrant NAS box and using their X-RAID instead.
I've gone back to solaris from an Infrant box.
1) while the Infrant cpu is sparc, its way, way, slow.
a) the web IU takes 3-5 seconds per page
b) any local process, rsync, UPnP, SlimServer is cpu starved
2) like a netapp,
Jeff Bonwick said:
RAID-Z takes a different approach. We were designing a filesystem
as well, so we could make the block pointers as semantically rich
as we wanted. To that end, the block pointers in ZFS contains data
layout information. One nice side effect of this is that we don't
need
Scott Roberts [EMAIL PROTECTED] writes:
I've been reading through the documentation on ZFS, and was hoping I
could get some clarification and make sure I'm reading everything
right.
I'm looking to build a NAS box, using sata drives in a double parity
configuration (i.e. raidz2). This is
Just out of curiosity, what is the progress on allowing the addition of
drives to an existing RAIDZ (whether pool or udev). Particularly in the
case of udevs, the ability to add additional drives to expand a udev is
really useful when adding more JBODs to an existing setup...
--
Erik Trimble
There are two questions here.
1. Can you add a redundant set of vdevs to a pool. Answer: yes.
2. What is the best way for Scott to grow his archive into his disks.
The answer to this is what I discuss below.
David Dyer-Bennet wrote:
Scott Roberts [EMAIL PROTECTED] writes:
I've been reading
On Wed, Jul 12, 2006 at 02:45:40PM -0700, Darren Dunham wrote:
There may be several parity sectors per row so adding another column doesn't
work.
But presumably it would be possible to use additional columns for future
writes?
I guess that could be made to work, but then the data on the
10 matches
Mail list logo
