On Sat, 30 Dec 2006 18:13:04 +0100, [EMAIL PROTECTED] wrote:
I think removing the ability to use link(2) or unlink(2) on directories
would hurt no-one and would make a few things easier.
I'd be rather carful here, see the standards implications drafted in
4917742.
The standard gives
David Bustos wrote:
Quoth Darren J Moffat on Thu, Dec 21, 2006 at 03:31:59PM +:
Pawel Jakub Dawidek wrote:
I like the idea, I really do, but it will be s expensive because of
ZFS' COW model. Not only file removal or truncation will call bleaching,
but every single file system
Darren J Moffat wrote:
...
Of course. I didn't mention it because I thought it was obvious but
this would NOT break the COW or the transactional integrity of ZFS.
One of the possible ways that the to be bleached blocks are dealt
with in the face of a crash is just like everything else -
Dmitry Mozheyko wrote:
Hello all.
Where i can find information about differences between fletcher2, fletcher4,
and sha256 algorithms for ZFS checksums?
Start here: http://en.wikipedia.org/wiki/Checksum
Then read up on Fletcher here at this link
I've ploughed through the documentation, but it's kind of vague on some points
and I need to buy some hardware if I'm to test it, so I thought I'd ask first.
I'll begin by describing what I want to achieve, and would apreciate if someone
could tell me if this is possible or how close I can
On 1/2/07, Anders Troberg [EMAIL PROTECTED] wrote:
I've ploughed through the documentation, but it's kind of vague on some
points and I need to buy some hardware if I'm to test it, so I thought I'd
ask first. I'll begin by describing what I want to achieve, and would
apreciate if someone could
it seems taking a clone always requires taking a snapshot first and provide
this as a parameter
to the zfs clone command.
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
I am bringing this up again with the hopes that more eye may be on the list
now then before the holidays..
the zfs man page lists the usage column as:
used
The amount of space consumed by this dataset and all its
descendants. This is the value that is checked against
Sorry a few corrections, and inserts..
which is not the behavior I am seeing.. If I have 100 snaps of a
filesystem that are relatively low delta churn and then delete half of
the
data out there I would expect to see that space go up in the used column
for one of the snaps (in my tests
james hughes wrote:
This is intended as a defense in depth measure and also a sufficiently
good measure for the customers that don't need full compliance with
NIST like requirements that need degausing or physical destruction.
Govt, finance, healthcare all require the NIST overwrite...
Played over Xmas a bit with ZFS on mirrored USB sticks. Which was fun
When I pulled both sticks without doing any unmount, the filesystem
seemed to be still there, all in cache of course. I even could open a
file in vi, but when I then tried to save the file, I had expected a
failure, but
I had a user report extreme slowness on a ZFS filesystem mounted over NFS over
the weekend.
After some extensive testing, the extreme slowness appears to only occur when a
ZFS filesystem is mounted over NFS.
One example is doing a 'gtar xzvf php-5.2.0.tar.gz'... over NFS onto a ZFS
Hi Brad,
I believe benr experienced the same/similar issue here:
http://www.opensolaris.org/jive/message.jspa?messageID=77347
If it is the same, I believe its a known ZFS/NFS interaction bug, and
has to do with small file creation.
Best Regards,
Jason
On 1/2/07, Brad Plecs [EMAIL PROTECTED]
You may want to check some of the past postings to this list as I believe
what you are seeing has already been discussed already. If I remember
correctly this is a feature of zfs and is designed to protect the
integrity of the data on the zfs file system.
On 1/2/07, Willem van Schaik [EMAIL
Ah, thanks -- reading that thread did a good job of explaining what I was
seeing. I was going
nuts trying to isolate the problem.
Is work being done to improve this performance? 100% of my users are coming in
over NFS,
and that's a huge hit. Even on single large files, writes are slower by
Brad Plecs wrote:
I had a user report extreme slowness on a ZFS filesystem mounted over NFS over the weekend.
After some extensive testing, the extreme slowness appears to only occur when a ZFS filesystem is mounted over NFS.
One example is doing a 'gtar xzvf php-5.2.0.tar.gz'... over NFS
Another thing to keep an eye out for is disk caching. With ZFS,
whenever the NFS server tells us to make sure something is on disk, we
actually make sure it's on disk by asking the drive to flush dirty data
in its write cache out to the media. Needless to say, this takes a
while.
With
On Jan 2, 2007, at 11:14, Richard Elling wrote:
Don't dispense with proper backups or you will be unhappy. One
of my New Years resolutions is to campaign against unhappiness.
So I would encourage you to explore ways to backup such large
data stores in a timely and economical way.
The Sun
We have some HDS storage that isn't supported by mpxio, so we have to use
veritas dmp to get multipathing.
Whats the recommended way to use DMP storage with ZFS. I want to use DMP but
get at the multipathed virtual luns at as low a level as possible to avoid
using vxvm as much as possible.
I
19 matches
Mail list logo
