Let's suppose you rename a file or directory.
/tank/widgets/a/rel2049_773.13-4/somefile.txt
Becomes
/tank/widgets/b/foogoo_release_1.9/README
Let's suppose you are now working on widget B, and you want to look at the
past zfs snapshot of README, but you don't remember where it came from.
Tha
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> If something like this already exists, please let me know. Otherwise,
> I
> plan to:
>
> Create "zfshistory" command, written in pyt
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Roy Sigurd Karlsbakk
>
> With 2TB drives priced at €150 or lower, I somehow think paying for
> drive lifetime is far more expensive than getting a few more drives and
> add redundancy
If you h
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Roy Sigurd Karlsbakk
>
> About SAS vs SATA, I'd guess you won't be able to see any change at
> all. The bottleneck is the drives, not the interface to them.
That doesn't agree with my understa
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Travis Tabbal
Oh, one more thing. Your subject says "ZIL/L2ARC" and your message says "I
want to speed up NFS writes."
ZIL (log) is used for writes.
L2ARC (cache) is used for reads.
I'd reco
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Travis Tabbal
>
> I have a few old drives here that I thought might help me a little,
> though not at much as a nice SSD, for those uses. I'd like to speed up
> NFS writes, and there have been
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Dave Pooser
>
> (lots of small writes/reads), how much benefit will I see from the SAS
> interface?
In some cases, SAS outperforms SATA. I don't know what circumstances those
are.
I think th
> From: Ian Collins [mailto:i...@ianshome.com]
> Sent: Sunday, April 25, 2010 5:09 PM
> To: Edward Ned Harvey
> Cc: 'Robert Milkowski'; zfs-discuss@opensolaris.org
> Subject: Re: [zfs-discuss] ZFS Pool, what happen when disk failure
>
> On 04/26/10 12:08 AM, Edward
> From: Richard Elling [mailto:richard.ell...@gmail.com]
> Sent: Sunday, April 25, 2010 2:12 PM
>
> > E did exist. Inode 12345 existed, but it had a different name at the
> time
>
> OK, I'll believe you.
>
> How about this?
>
> mv a/E/c a/c
> mv a/E a/c
> mv a/c a/E
The thin
> From: Richard Elling [mailto:richard.ell...@gmail.com]
> Sent: Saturday, April 24, 2010 7:42 PM
>
> Next,
> mv /a/e /a/E
> ls -l a/e/.snapshot/snaptime
>
> ENOENT?
>
> ls -l a/E/.snapshot/snapname/d.txt
>
> this should be ENOENT because d.txt did not exist in a/E at snaptime
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Freddie Cash
>
> From the sounds of it, the .snapshot directory is just a pointer to the
> corresponding directory in the actual snapshot tree. The snapshots are
> not actually saved per-direc
> From: Ragnar Sundblad [mailto:ra...@csc.kth.se]
> Sent: Saturday, April 24, 2010 5:18 PM
>
> > To answer the question you linked to:
> > .shapshot/snapname.0/a/b/c/d.txt from the top of the filesystem
> > a/.snapshot/snapname.0/b/c/d.txt
> > a/e/.shapshot/snapname.0/c/d.txt
> > a/e/c/.snapshot/sn
> From: Richard Elling [mailto:richard.ell...@gmail.com]
> Sent: Saturday, April 24, 2010 10:43 AM
>
> > Nope. That discussion seems to be concluded now. And the netapp
> does not
> > have the problem that was suspected.
>
> I do not recall reaching that conclusion. I think the definition of
>
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Peter Tripp
> here, I'll swap it in for the sparse file and let it resilver.
>
> Can someone with a stronger understanding of ZFS tell me why a degraded
> RaidZ2 (minus one disk) is less effici
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Robert Milkowski
>
> On 24/04/2010 13:51, Edward Ned Harvey wrote:
> > But what you might not know: If any pool fails, the system will
> crash.
> This actually
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of aneip
>
> I really new to zfs and also raid.
>
> I have 3 hard disk, 500GB, 1TB, 1.5TB.
>
> On each HD i wanna create 150GB partition + remaining space.
>
> I wanna create raidz for 3x150GB
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Haudy Kazemi
>
> Your remaining space can be configured as slices. These slices can be
> added directly to a second pool without any redundancy. If any drive
> fails, that whole non-redundant
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
> >
> > Actu
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> Actually, I find this very surprising:
> Question posted:
> http://lopsa.org/pipermail/tech/2010-April/004356.html
As the thread unfolds, it appears, a
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> One last try. If you change the "real" directory structure, how are
> those
> changes reflected in the "snapshot" directory structure?
>
> Consider:
> echo "whee" > /a/b/c/d.txt
> [snapshot]
> mv /a/b /a/B
>
> What do
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of thomas
>
> Someone on this list threw out the idea a year or so ago to just setup
> 2 ramdisk servers, export a ramdisk from each and create a mirror slog
> from them.
Isn't the whole point of
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> Repeating my previous question in another way...
> So how do they handle "mv home/joeuser home/moeuser" ?
> Does that mv delete all snapshots below home/joeuser?
> To make this work in ZFS, does this require that the mv(1)
> command only
> If you did the symlink .snapshot --> $FSROOT/.zfs/snapshot, and somehow
> made
> that magically appear in every directory all the time, you would have
> this:
> /share/home/joeuser/foo/.snapshot/bestsnapever/home/joeuser/foo/bar
> /share/home/joeuser/.snapshot/bestsnapever/home/joeuser/foo/bar
>
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> So you are saying that the OnTap .snapshot directory is equivalent to a
> symlink
> to $FSROOT/.zfs/snapshot? That would "solve" the directory shuffle
> problem.
Not quite.
In Ontap, all you do is go into .snapshot, and select which
> From: Nicolas Williams [mailto:nicolas.willi...@oracle.com]
>
> POSIX doesn't allow us to have special dot files/directories outside
> filesystem root directories.
So? Tell it to Netapp. They don't seem to have any problem with it.
___
zfs-discuss
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> >> What happens when you remove the directory?
> >
> > Same thing that happens when you remove the .zfs directory. You
> can't.
>
> Are you sure I cannot rmdir on a NetApp? That seems like basic
> functionality to me.
>
> Or are you
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> On Apr 20, 2010, at 10:21 PM, Brandon High wrote:
>
> > On Fri, Apr 16, 2010 at 10:54 AM, Edward Ned Harvey
> > wrote:
> >> there's a file or something you want to rollback, it's presently
&
> From: Brandon High [mailto:bh...@freaks.com]
>
> On Fri, Apr 16, 2010 at 10:54 AM, Edward Ned Harvey
> wrote:
> > there's a file or something you want to rollback, it's presently
> difficult
> > to know how far back up the tree you need to go, to find the c
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Tim Haley
>
> You can see it with ls:
> # ls -ld -% all /net/server/export/ws/timh/nvc
> drwxr-xr-x 9 timh staff 13 Apr 21 01:25
> /net/server/export/ws/timh/nvc/
> time
> From: Mark Shellenbaum [mailto:mark.shellenb...@oracle.com]
> >
> > You can create/destroy/rename snapshots via mkdir, rmdir, mv inside
> the
> > .zfs/snapshot directory, however, it will only work if you're running
> the
> > command locally. It will not work from a NFS client.
> >
>
> It will
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Nicolas Williams
> >
> > An
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Nicolas Williams
>
> The .zfs/snapshot directory is most certainly available over NFS.
I'm not sure you've been following this thread. Nobody said .zfs/snapshot
wasn't available over NFS. It
> From: cas...@holland.sun.com [mailto:cas...@holland.sun.com] On Behalf
> Of casper@sun.com
>
> >On Mon, 19 Apr 2010, Edward Ned Harvey wrote:
> >> Improbability assessment aside, suppose you use something like the
> DDRDrive
> >> X1 ... Which might be m
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us]
>
> On Mon, 19 Apr 2010, Edward Ned Harvey wrote:
> >
> > Just be aware that if *any* of your devices fail, all is lost.
> (Because
> > you've said it's configured as a nonredundant stripe.)
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Albert Frenz
>
> since i am really new to zfs, i got 2 important questions for starting.
> i got a nas up and running zfs in stripe mode with 2x 1,5tb hdd. my
> question for future proof would
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Don
>
> Continuing on the best practices theme- how big should the ZIL slog
> disk be?
>
> The ZFS evil tuning guide suggests enough space for 10 seconds of my
> synchronous write load- even a
> From: Kyle McDonald [mailto:kmcdon...@egenera.com]
>
> I think I saw an ARC case go by recently for anew 'zfs diff' command. I
> think it allows you compare 2 snapshots, or maybe the live filesystem
> and a snapshot and see what's changed.
>
> It sounds really useful, Hopefully it will integrate
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us]
> Sent: Sunday, April 18, 2010 11:34 PM
> To: Edward Ned Harvey
> Cc: Christopher George; zfs-discuss@opensolaris.org
> Subject: RE: [zfs-discuss] SSD best practices
>
> On Sun, 18 Apr 2010, Edward Ned Harvey wrot
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Don
>
> I've got 80 spindles in 5 16 bay drive shelves (76 15k RPM SAS drives
> in 19 4 disk raidz sets, 2 hot spares, and 2 bays set aside for a
> mirrored ZIL) connected to two servers (so if
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
>
> On Sun, 18 Apr 2010, Christopher George wrote:
> >
> > In summary, the DDRdrive X1 is designed, built and tested with
> immense
> > pride and an overwhelming attention to de
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Dave Vrona
>
> > On 18 apr 2010, at 00.52, Dave Vrona wrote:
> >
> > > Ok, so originally I presented the X-25E as a
> > "reasonable" approach. After reading the follow-ups,
> > I'm second gues
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> On Apr 17, 2010, at 11:51 AM, Edward Ned Harvey wrote:
>
> > For zpool < 19, which includes all present releases of Solaris 10 and
> > Opensolaris 2009.06, it is critical to mirror your ZIL log device. A
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Dave Vrona
> >
>
> > 2) ZI
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Dave Vrona
>
> 1) Mirroring. Leaving cost out of it, should ZIL and/or L2ARC SSDs be
> mirrored ?
IMHO, the best answer to this question is the one from the ZFS Best
Practices guide. (I wrot
> From: Ian Collins [mailto:i...@ianshome.com]
>
> But is a fundamental of zfs:
>
> snapshot
>
> A read-only version of a file system or volume at a
> given point in time. It is specified as filesys...@name
> or vol...@name.
Erik Trimble's assessment tha
> From: Erik Trimble [mailto:erik.trim...@oracle.com]
>
> > So the suggestion, or question is: Is it possible or planned to
> implement a
> > rollback command, that works as fast as a link or re-link operation,
> > implemented at a file or directory level, instead of the entire
> filesystem?
> >
> From: Richard Elling [mailto:richard.ell...@gmail.com]
> >
> > Um ... All the same time.
> > Even if I "stat" those directories ...
> > Access: Modify: and Change: are all useless...
>
> which is why you need to stat the destination :-)
Ahh. I see it now.
By stat'ing the destination instead
> From: Nicolas Williams [mailto:nicolas.willi...@oracle.com]
>
> you should send your snapshots to backup and clean them out from
> time to time anyways.
When using ZFS as a filesystem in a fileserver, the desired configuration
such as auto-snapshots is something like:
Every 15 mins for t
> From: Erik Trimble [mailto:erik.trim...@oracle.com]
> Sent: Friday, April 16, 2010 7:35 PM
>
> > Doesn't that defeat the purpose of a snapshot?
> >
> Eric hits
> the
> nail right on the head: you *don't* want to support such a "feature",
> as it breaks the fundamental assumption about what a sn
> From: Erik Trimble [mailto:erik.trim...@oracle.com]
>
> Not to be a contrary person, but the job you describe above is properly
> the duty of a BACKUP system. Snapshots *aren't* traditional backups,
> though some people use them as such. While I see no technical reason
> why snapshots couldn'
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> There are some interesting design challenges here. For the general
> case, you
> can't rely on the snapshot name to be in time order, so you need to
> sort by the
> mtime of the destination.
Actually ...
drwxr-xr-x 16 root root 20 Ma
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Willard Korfhage
>
> devfsadm -Cv gave a lot of "removing file" messages, apparently for
> items that were not relevant.
That's good. If there were no necessary changes, devfsadm would say
no
The typical problem scenario is: Some user or users fill up the filesystem.
They rm some files, but disk space is not freed. You need to destroy all
the snapshots that contain the deleted files, before disk space is available
again.
It would be nice if you could rm files from snapshots, without
If you've got nested zfs filesystems, and you're in some subdirectory where
there's a file or something you want to rollback, it's presently difficult
to know how far back up the tree you need to go, to find the correct ".zfs"
subdirectory, and then you need to figure out the name of the snapshots
AFAIK, if you want to restore a snapshot version of a file or directory, you
need to use "cp" or such commands, to copy the snapshot version into the
present. This is not done in-place, meaning, the "cp" or whatever tool must
read the old version of objects and write new copies of the objects. Yo
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Tonmaus
>
> are the drives properly configured in cfgadm?
I agree. You need to do these:
devfsadm -Cv
cfgadm -al
___
zfs-discuss m
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of John
>
> Just to add more details, the issue only occurred for the first direct
> access to the file.
> From a windows client that has never access the file, you can issue:
> dir \\filer\arch\m
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Daniel
>
> Im pretty new to the whole OpenSolaris thing, i've been doing a bit of
> research but cant find anything on what i need.
>
> I am thinking of making myself a home file server runnin
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>
> I am trying to duplicate a filesystem from one zpool to another zpool.
> I don't care so much about snapshots on the destination side...I am
> more trying to duplicate how RSYNC would copy a filesystem, and then
> only copy incre
> Carson Gaspar wrote:
>
> Does anyone who understands the internals better than care to take a
> stab at what happens if:
>
> - ZFS writes data to /dev/foo
> - /dev/foo looses power and the data from the above write, not yet
> flushed to rust (say a field tech pulls the wrong drive...)
> - /dev/
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Eric D. Mudama
>
> I believe the reason strings of bits "leak" on rotating drives you've
> overwritten (other than grown defects) is because of minute off-track
> occurances while writing (vibr
> From: Daniel Carosone [mailto:d...@geek.com.au]
>
> Please look at the pool property "failmode". Both of the preferences
> you have expressed are available, as well as the default you seem so
> unhappy with.
I ... did not know that. :-)
Thank you.
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> On Apr 11, 2010, at 5:36 AM, Edward Ned Harvey wrote:
> >
> > In the event a pool is faulted, I wish you didn't have to power cycle
> the
> > machine. Let all the zfs filesystems that are in that
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> wrote:
> > Hi all
> >
> > Is it possible to securely delete a file from a zfs dataset/zpool
> once it's been snapshotted, meaning "delete (and perhaps overwrite) all
> copies of this file"?
>
> No, until all snapshots referencing
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>
> Thanks for the testing. so FINALLY with version > 19 does ZFS
> demonstrate production-ready status in my book. How long is it going to
> take Solaris to catch up?
Oh, it's been production worthy for some time - Just don't use u
> From: Tim Cook [mailto:t...@cook.ms]
>
> Awesome! Thanks for letting us know the results of your tests Ed,
> that's extremely helpful. I was actually interested in grabbing some
> of the cheaper intel SSD's for home use, but didn't want to waste my
> money if it wasn't going to handle the vari
Neil or somebody? Actual ZFS developers? Taking feedback here? ;-)
While I was putting my poor little server through cruel and unusual
punishment as described in my post a moment ago, I noticed something
unexpected:
I expected that while I'm stressing my log device by infinite sync writ
Due to recent experiences, and discussion on this list, my colleague and I
performed some tests:
Using solaris 10, fully upgraded. (zpool 15 is latest, which does not have
log device removal that was introduced in zpool 19) In any way possible,
you lose an unmirrored log device, and the OS wi
> -Original Message-
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Daniel Bakken
>
> My zfs filesystem hangs when transferring large filesystems (>500GB)
> with a couple dozen snapshots between servers using zfs send/receive
> with
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Eric Andersen
>
> I backup my pool to 2 external 2TB drives that are simply striped using
> zfs send/receive followed by a scrub. As of right now, I only have
> 1.58TB of actual data. ZFS sen
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> I don't know how to identify what card is installed in your system.
Actually, this is useful:
prtpicl -v | less
Search for RAID. On my system, I get
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Andreas Höschler
>
> > I don't think that the BIOS and rebooting part ever has to be true,
> > at least I don't hope so. You shouldn't have to reboot just because
> > you replace a hot plug dis
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of David Magda
>
> If you're going to go with (Open)Solaris, the OP may also want to look
> into the multi-platform pkgsrc for third-party open source software:
>
> http://www.pkgsrc.org/
>
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Chris Dunbar
>
> like to clarify something. If read performance is paramount, am I
> correct in thinking RAIDZ is not the best way to go? Would not the ZFS
> equivalent of RAID 10 (striped mirro
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
>
> It is also worth pointing out that in normal operation the slog is
> essentially a write-only device which is only read at boot time. The
> writes are assumed to work if th
> From: Ragnar Sundblad [mailto:ra...@csc.kth.se]
>
> Rather: ... >=19 would be ... if you don't mind loosing data written
> the ~30 seconds before the crash, you don't have to mirror your log
> device.
If you have a system crash, *and* a failed log device at the same time, this
is an important c
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jeroen Roodhart
>
> > If you're running solaris proper, you better mirror
> > your
> > > ZIL log device.
> ...
> > I plan to get to test this as well, won't be until
> > late next week though.
> > We ran into something similar with these drives in an X4170 that
> turned
> > out to
> > be an issue of the preconfigured logical volumes on the drives. Once
> > we made
> > sure all of our Sun PCI HBAs where running the exact same version of
> > firmware
> > and recreated the volumes on new d
> I have reason to believe that both the drive, and the OS are correct.
> I have suspicion that the HBA simply handled the creation of this
> volume somehow differently than how it handled the original. Don't
> know the answer for sure yet.
Ok, that's confirmed now. Apparently when the drives sh
> From: Kyle McDonald [mailto:kmcdon...@egenera.com]
>
> So does your HBA have newer firmware now than it did when the first
> disk
> was connected?
> Maybe it's the HBA that is handling the new disks differently now, than
> it did when the first one was plugged in?
>
> Can you down rev the HBA FW
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Andreas Höschler
>
> Thanks for the clarification! This is very annoying. My intend was to
> create a log mirror. I used
>
> zpool add tank log c1t6d0 c1t7d0
>
> and this was obviously f
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Marcus Wilhelmsson
> pool: s1
> state: ONLINE
> scrub: none requested
> config:
>
> NAMESTATE READ WRITE CKSUM
> s1 ONLINE 0 0 0
>
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Andreas Höschler
>
> I would like to remove the two SSDs as log devices from the pool and
> instead add them as a separate pool for sole use by the database to
> see how this enhences perform
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Marcus Wilhelmsson
>
> I have a problem with my zfs system, it's getting slower and slower
> over time. When the OpenSolaris machine is rebooted and just started I
> get about 30-35MB/s in read
I haven't taken that approach, but I guess I'll give it a try.
From: Tim Cook [mailto:t...@cook.ms]
Sent: Sunday, April 04, 2010 11:00 PM
To: Edward Ned Harvey
Cc: Richard Elling; zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] To slice, or not to slice
On Sun, A
> > There is some question about performance. Is there any additional
> overhead caused by using a slice instead of the whole physical device?
>
> No.
>
> If the disk is only used for ZFS, then it is ok to enable volatile disk
> write caching
> if the disk also supports write cache flush request
> Actually, It's my experience that Sun (and other vendors) do exactly
> that for you when you buy their parts - at least for rotating drives, I
> have no experience with SSD's.
>
> The Sun disk label shipped on all the drives is setup to make the drive
> the standard size for that sun part number
> Hmm, when you did the write-back test was the ZIL SSD included in the
> write-back?
>
> What I was proposing was write-back only on the disks, and ZIL SSD
> with no write-back.
The tests I did were:
All disks write-through
All disks write-back
With/without SSD for ZIL
All the permutations of th
> CR 6844090, zfs should be able to mirror to a smaller disk
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6844090
> b117, June 2009
Awesome. Now if someone would only port that to solaris, I'd be a happy
man. ;-)
___
zfs-discuss maili
> Your experience is exactly why I suggested ZFS start doing some "right
> sizing" if you will. Chop off a bit from the end of any disk so that
> we're guaranteed to be able to replace drives from different
> manufacturers. The excuse being "no reason to, Sun drives are always
> of identical size
> When running the card in copyback write cache mode, I got horrible
> performance (with zfs), much worse than with copyback disabled
> (which I believe should mean it does write-through), when tested
> with filebench.
When I benchmark my disks, I also find that the system is slower with
WriteBack
> Your original zpool status says that this pool was last accessed on
> another system, which I believe is what caused of the pool to fail,
> particularly if it was accessed simultaneously from two systems.
The message "last accessed on another system" is the normal behavior if the
pool is ungrace
> I would return the drive to get a bigger one before doing something as
> drastic as that. There might have been a hichup in the production line,
> and that's not your fault.
Yeah, but I already have 2 of the replacement disks, both doing the same
thing. One has a firmware newer than my old disk
> On Apr 2, 2010, at 2:29 PM, Edward Ned Harvey wrote:
> > I've also heard that the risk for unexpected failure of your pool is
> higher if/when you reach 100% capacity. I've heard that you should
> always create a small ZFS filesystem within a pool, and give it some
>
>> And finally, if anyone has experience doing this, and process
>> recommendations? That is
My next task is to go read documentation
>> again, to refresh my memory from years ago, about the difference
>> between format, partition, label, fdisk, because those terms
>> dont have the same
> > One reason to slice comes from recent personal experience. One disk
> of
> > a mirror dies. Replaced under contract with an identical disk. Same
> > model number, same firmware. Yet when it's plugged into the system,
> > for an unknown reason, it appears 0.001 Gb smaller than the old disk,
> >
Momentarily, I will begin scouring the omniscient interweb for information, but
I'd like to know a little bit of what people would say here. The question is
to slice, or not to slice, disks before using them in a zpool.
One reason to slice comes from recent personal experience. One disk of a
g
with the filesystem that you actually plan to use in your pool. Anyone care
to offer any comments on that?
From: zfs-discuss-boun...@opensolaris.org
[mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
Sent: Friday, April 02, 2010 5:23 PM
To: zfs-discuss@opensolaris.o
Momentarily, I will begin scouring the omniscient interweb for information,
but I'd like to know a little bit of what people would say here. The
question is to slice, or not to slice, disks before using them in a zpool.
One reason to slice comes from recent personal experience. One disk of a
> The purpose of the ZIL is to act like a fast "log" for synchronous
> writes. It allows the system to quickly confirm a synchronous write
> request with the minimum amount of work.
Bob and Casper and some others clearly know a lot here. But I'm hearing
conflicting information, and don't know
901 - 1000 of 1156 matches
Mail list logo
