Is there some reason why a small read on a raidz2 is not statistically very
likely to require I/O on only one device? Assuming a non-degraded pool of
course.
ZFS stores its checksums for RAIDZ/RAIDZ2 in such a way that all disks must be
read to compute and
verify the checksum.
But why
Hello Anton,
Thursday, January 4, 2007, 3:46:48 AM, you wrote:
Is there some reason why a small read on a raidz2 is not statistically very
likely to require I/O on only one device? Assuming a non-degraded pool of
course.
ABR ZFS stores its checksums for RAIDZ/RAIDZ2 in such a way that all
Matthew Ahrens wrote:
now wouldnt it be more natural way of usage when I intend to create a
clone, that by default
the zfs clone command will create the needed snapshot from the current
image internally as part
of taking the clone unless I explicitely specify that I do want to
take a clone of
Hi,
I've tried to create zfs pool on my c0d0s7 and use it as a tank for my
/export/home
Everything was perfect, I moved my files from a backup there and still ok.
I also deleted old line with ufs mountpoint /export/home in vfstab file.
But after reboot, there was just bash shell. I've tried to
I am not sure what your problem is. Does it not start dtlogin/gdm ? Or is the zpool not
mounted ? Just run after login on cli and run svcs -x and df -k to see if all services
are running and the zpool has been mounted. It can be that your zpool was not mounted on
/export (depending on your
On Jan 4, 2007, at 3:25 AM, [EMAIL PROTECTED] wrote:
Is there some reason why a small read on a raidz2 is not
statistically very
likely to require I/O on only one device? Assuming a non-degraded
pool of
course.
ZFS stores its checksums for RAIDZ/RAIDZ2 in such a way that all
disks must
So actually I mis-spoke slightly; rather than all disks, I should
have said all data disks.
In practice this has the same effect: No more than one read may be
processed at a time.
But aren't short blocks sometimes stored on only a subset of disks?
Casper
It's the block checksum that requires reading all of the disks. If
ZFS stored sub-block checksums for the RAID-Z case then short reads
could often be satisfied without reading the whole block (and all
disks).
What happens when a sub-block is missing (single disk failure)? Surely
it doesn't
Anton B. Rang writes:
In our recent experience RAID-5 due to the 2 reads, a XOR calc and a
write op per write instruction is usually much slower than RAID-10
(two write ops). Any advice is greatly appreciated.
RAIDZ and RAIDZ2 does not suffer from this malady (the RAID5 write
On Jan 4, 2007, at 10:26 AM, Roch - PAE wrote:
All filesystems will incur a read-modify-write when
application is updating portion of a block.
For most Solaris file systems it is the page size, rather than
the block size, that affects read-modify-write; hence 8K (SPARC)
or 4K
[EMAIL PROTECTED] wrote on 01/03/2007 04:21:00 PM:
[EMAIL PROTECTED] wrote:
which is not the behavior I am seeing..
Show me the output, and I can try to explain what you are seeing.
[9:36am] [~]:test% zfs create data/test
[9:36am] [~]:test% zfs set compression=on data/test
[9:37am]
What happens when a sub-block is missing (single disk failure)? Surely
it doesn't have to discard the entire checksum and simply trust the
remaining blocks?
The checksum is over the data, not the data+parity. So when a disk fails,
the data is first reconstructed, and then the block checksum
From what I have read, it looks like there is a known issue with scrubbing
restarting when any of the other usages of the same code path run
(re-silver, snap ...). It looks like there is a plan to put in a marker so
that scrubbing knows where to start again after being preempted. This is
Darren Dunham wrote:
Is the problem of displaying the potential space freed by multiple
destructions one of calculation (do you have to walk snapshot trees?) or
one of formatting and display?
Both, because you need to know for each snapshot, how much of the data
it references was first
errors: The following persistent errors have been detected:
DATASET OBJECT RANGE
z_tsmsun1_pool/tsmsrv1_pool 26208464760832-8464891904
Looks like I have possibly a single file that is corrupted. My question is how do I find the file. Is it as
[EMAIL PROTECTED] wrote:
[9:40am] [/data/test]:test% zfs snapshot data/[EMAIL PROTECTED]
[9:41am] [/data/test]:test% zfs snapshot data/[EMAIL PROTECTED]
...
[9:42am] [/data/test/images/fullres]:test% zfs list
NAME USED AVAIL REFER MOUNTPOINT
data/test 13.4G
Matthew,
I really do appreciate this discussion, thank you for taking the time to
go over this with me.
Matthew Ahrens [EMAIL PROTECTED] wrote on 01/04/2007 01:49:00 PM:
[EMAIL PROTECTED] wrote:
[9:40am] [/data/test]:test% zfs snapshot data/[EMAIL PROTECTED]
[9:41am]
On 03 January, 2007 - [EMAIL PROTECTED] sent me these 0,5K bytes:
Hmmm, so there is lots of evictable cache here (mostly in the MFU
part of the cache)... could you make your core file available?
I would like to take a look at it.
Isn't this just like:
6493923 nfsfind on ZFS filesystem
I'm being a bit of a dunderhead at the moment and neither the site search
nor
google are picking up the information I seek...
I'm setting up a thumper and I'm sure I recall some discussion of the
optimal
number of drives in raidz1 and raidz2 vdevs. I also recall that it was
something
like you
[EMAIL PROTECTED] wrote:
Common case to me is, how much would be freed by deleting the snapshots in
order of age from oldest to newest always starting with the oldest.
That would be possible. A given snapshot's space used by this and all
prior snapshots would be the prev snap's used+prior +
Hi All,
As you all know that DIRECT IO is not supported by ZFS file sytem. When ZFS
people will add DIRECT IO support to ZFS ? What is the roadmap for ZFS direct
IO ? Do you have any idea on this, Please let me know.
Thanks Regards
Masthan
21 matches
Mail list logo
