I have a system with a bunch of disks, and I¹d like to know how much faster
it would be if I had an SSD for the ZIL; however, I don¹t have the SSD and I
don¹t want to buy one right now. The reasons are complicated, but it¹s not
a cost barrier. Naturally I can¹t do the benchmark right now...
But
I don't know the answer to your question, but I am running the same version
of OS you are, and this bug could affect us. Do you have any link to any
documentation about this bug? I'd like to forward something to inform the
other admins at work.
From: zfs-discuss-boun...@opensolaris.org
Sorry for double-post. This thread was posted separately to
opensolaris-help and zfs-discuss. So I'm replying to both lists.
> I'm wondering what the possibilities of two-way replication are for a
> ZFS storage pool.
Based on all the description you gave, I wouldn't call this two-way
replicati
> Is there any work on an upgrade of zfs send/receive to handle resuming
> on next media?
Please see Darren's post, pasted below.
> -Original Message-
> From: opensolaris-discuss-boun...@opensolaris.org [mailto:opensolaris-
> discuss-boun...@opensolaris.org] On Behalf Of Darren Mackay
>
> Is there any work on an upgrade of zfs send/receive to handle resuming
> on next media?
See Darren's post, regarding mkfifo. The purpose is to enable you to use
"normal" backup tools that support changing tapes, to backup your "zfs send"
to multiple split tapes. I wonder though - During a rest
In this email, when I say PERC, I really mean either a PERC, or any other
hardware WriteBack buffered raid controller with BBU.
For future server purchases, I want to know which is faster: (a) A bunch of
hard disks with PERC and WriteBack enabled, or (b) A bunch of hard disks,
plus one SSD for
Recently, I'm benchmarking all kinds of stuff on my systems. And one
question I can't intelligently answer is what blocksize I should use in
these tests.
I assume there is something which monitors present disk activity, that I
could run on my production servers, to give me some statistics of t
> From everything I've seen, an SSD wins simply because it's 20-100x the
> size. HBAs almost never have more than 512MB of cache, and even fancy
> SAN boxes generally have 1-2GB max. So, HBAs are subject to being
> overwhelmed with heavy I/O. The SSD ZIL has a much better chance of
> being able to
> You are running into this bug:
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6929751
> Currently, building a pool from files is not fully supported.
I think Cindy and I interpreted the question differently. If you want the
zpool inside a file to stay mounted while the system is r
> It all depends on how they are connecting to the storage. iSCSI, CIFS,
> NFS,
> database, rsync, ...?
>
> The reason I say this is because ZFS will coalesce writes, so just
> looking at
> iostat data (ops versus size) will not be appropriate. You need to
> look at the
> data flowing between ZF
I don't have an answer to this question, but I can say, I've seen a similar
surprising result. I ran iozone on various raid configurations of spindle
disks . and on a ramdisk. I was surprised to see the ramdisk is only about
50% to 200% faster than the next best competitor in each category. . I d
> In my case where I reboot the server I cannot get the pool to come
> back up. It shows UNAVAIL, I have tried to export before reboot and
> reimport it and have not been successful and I dont like this in the
> case a power issue of some sort happens. My other option was to mount
> using lofiadm h
> I don't think retransmissions of b0rken packets is a problem anymore,
> most people
> use ssh which provides good error detection at a fine grain. It is
> rare that one would
> need to resend an entire ZFS dump stream when using ssh (or TLS or ...)
>
> Archival tape systems are already designed
In addition to backups on tape, I like to backup my ZFS to removable hard
disk. (Created a ZFS filesystem on removable disk, and "zfs send | zfs
receive" onto the removable disk). But since a single hard disk is so prone
to failure, I like to scrub my external disk regularly, just to verify the
d
> The one thing that I keep thinking, and which I have yet to see
> discredited, is that
> ZFS file systems use POSIX semantics. So, unless you are using
> specific features
> (notably ACLs, as Paul Henson is), you should be able to backup those
> file systems
> using well known tools.
This is
> I think what you're saying is: Why bother trying to backup with "zfs
> send"
> when the recommended practice, fully supportable, is to use other tools
> for
> backup, such as tar, star, Amanda, bacula, etc. Right?
>
> The answer to this is very simple.
> #1 ...
> #2 ...
Oh, one more thing.
> Why do we want to adapt "zfs send" to do something it was never
> intended
> to do, and probably won't be adapted to do (well, if at all) anytime
> soon instead of
> optimizing existing technologies for this use case?
The only time I see or hear of anyone using "zfs send" in a way it wasn't
inte
> My own stuff is intended to be backed up by a short-cut combination --
> zfs send/receive to an external drive, which I then rotate off-site (I
> have three of a suitable size). However, the only way that actually
> works so far is to destroy the pool (not just the filesystem) and
> recreate it
> From what I've read so far, zfs send is a block level api and thus
> cannot be
> used for real backups. As a result of being block level oriented, the
Weirdo. The above "cannot be used for real backups" is obviously
subjective, is incorrect and widely discussed here, so I just say "weirdo."
I'm
> > From what I've read so far, zfs send is a block level api and thus
> > cannot be
> > used for real backups. As a result of being block level oriented, the
>
> Weirdo. The above "cannot be used for real backups" is obviously
> subjective, is incorrect and widely discussed here, so I just say
>
> > ZFS+CIFS even provides
> > Windows Volume Shadow Services so that Windows users can do this on
> > their own.
>
> I'll need to look into that, when I get a moment. Not familiar with
> Windows Volume Shadow Services, but having people at home able to do
> this
> directly seems useful.
I'd lik
> > ZFS+CIFS even provides
> > Windows Volume Shadow Services so that Windows users can do this on
> > their own.
>
> I'll need to look into that, when I get a moment. Not familiar with
> Windows Volume Shadow Services, but having people at home able to do
> this
> directly seems useful.
> > I'll say it again: neither 'zfs send' or (s)tar is an enterprise (or
> > even home) backup system on their own one or both can be components
> of
> > the full solution.
I would be pretty comfortable with a solution thusly designed:
#1 A small number of external disks, "zfs send" onto the dis
> 1. NDMP for putting "zfs send" streams on tape over the network. So
Tell me if I missed something here. I don't think I did. I think this
sounds like crazy talk.
I used NDMP up till November, when we replaced our NetApp with a Solaris Sun
box. In NDMP, to choose the source files, we had the
> It would appear that the bus bandwidth is limited to about 10MB/sec
> (~80Mbps) which is well below the theoretical 400Mbps that 1394 is
> supposed to be able to handle. I know that these two disks can go
> significantly higher since I was seeing 30MB/sec when they were used on
> Macs previously
> I have noted there is now raidz2 and been thinking witch woul be
> better.
> A pool with 2 mirrors or one pool with 4 disks raidz2
If you use raidz2, made of 4 disks, you will have usable capacity of 2
disks, and you can tolerate any 2 disks failing.
If you use 2 mirrors, you will have a total
> A pool with a 4-wide raidz2 is a completely nonsensical idea. It has
> the same amount of accessible storage as two striped mirrors. And would
> be slower in terms of IOPS, and be harder to upgrade in the future
> (you'd need to keep adding four drives for every expansion with raidz2
> - with mir
> > I'll say it again: neither 'zfs send' or (s)tar is an
> > enterprise (or
> > even home) backup system on their own one or both can
> > be components of
> > the full solution.
> >
>
> Up to a point. zfs send | zfs receive does make a very good back up
> scheme for the home user with a moderate
> 5+ years ago the variety of NDMP that was available with the
> combination of NetApp's OnTap and Veritas NetBackup did backups at the
> volume level. When I needed to go to tape to recover a file that was
> no longer in snapshots, we had to find space on a NetApp to restore
> the volume. It cou
> That would add unnecessary code to the ZFS layer for something that
> cron can handle in one line.
Actually ... Why should there be a ZFS property to share NFS, when you can
already do that with "share" and "dfstab?" And still the zfs property
exists.
I think the proposed existence of a ZFS sc
> Most software introduced in Linux clearly violates the "UNIX
> philosophy".
Hehehe, don't get me started on OSX. ;-) And for the love of all things
sacred, never say OSX is not UNIX. I made that mistake once. Which is not
to say I was proven wrong or anything - but it's apparently a subjec
> > The only tool I'm aware of today that provides a copy of the data,
> and all of the ZPL metadata and all the ZFS dataset properties is 'zfs
> send'.
>
> AFAIK, this is correct.
> Further, the only type of tool that can backup a pool is a tool like
> dd.
How is it different to backup a pool, v
> > ln -s .zfs/snapshot snapshots
> >
> > Voila. All Windows or Mac or Linux or whatever users are able to
> easily access snapshots.
>
> Clever.
>
> Just one minor problem though, you've circumvented the reason why the
> "snapdir"
> property defaults to "hidden." This probably won't affect cli
> >Actually ... Why should there be a ZFS property to share NFS, when you
> can
> >already do that with "share" and "dfstab?" And still the zfs property
> >exists.
>
> Probably because it is easy to create new filesystems and clone them;
> as
> NFS only works per filesystem you need to edit dfsta
> Does cron happen to know how many other scrubs are running, bogging
> down
> your IO system? If the scrub scheduling was integrated into zfs itself,
It doesn't need to.
Crontab entry: /root/bin/scruball.sh
/root/bin/scruball.sh:
#!/usr/bin/bash
for filesystem in filesystem1 filesystem2 filesy
> no, it is not a subdirectory it is a filesystem mounted on top of the
> subdirectory.
> So unless you use NFSv4 with mirror mounts or an automounter other NFS
> version will show you contents of a directory and not a filesystem. It
> doesn't matter if it is a zfs or not.
Ok, I learned something
> IIRC it's "zpool scrub", and last time I checked, the zpool command
> exited (with status 0) as soon as it had started the scrub. Your
> command
> would start _ALL_ scrubs in paralell as a result.
You're right. I did that wrong. Sorry 'bout that.
So either way, if there's a zfs property for s
> Not being a CIFS user, could you clarify/confirm for me.. is this
> just a "presentation" issue, ie making a directory icon appear in a
> gooey windows explorer (or mac or whatever equivalent) view for people
> to click on? The windows client could access the .zfs/snapshot dir
> via typed pathn
> This may be a bit dimwitted since I don't really understand how
> snapshots work. I mean the part concerning COW (copy on right) and
> how it takes so little room.
COW and snapshots are very simple to explain. Suppose you're chugging along
using your filesystem, and then one moment, you tell t
> In other words, there
> is no
> case where multiple scrubs compete for the resources of a single disk
> because
> a single disk only participates in one pool.
Excellent point. However, the problem scenario was described as SAN. I can
easily imagine a scenario where some SAN administrator crea
> > You can easily determine if the snapshot has changed by checking the
> > output of zfs list for the snapshot.
>
> Do you mean to just grep it out of the output of
>
> zfs list -t snapshot
I think the point is: You can easily tell how many MB changed in a
snapshot, and therefore you can ea
Is there a way to reserve space for a particular user or group? Or perhaps
to set a quota for a group which includes everyone else?
I have one big pool, which holds users' home directories, and also the
backend files for the svn repositories etc. I would like to ensure the svn
server process
> Thank you all for your valuable experience and fast replies. I see your
> point and will create one virtual disk for the system and one for the
> storage pool. My RAID controller is battery backed up, so I'll leave
> write caching on.
I think the point is to say: ZFS software raid is both faste
> zfs set reservation=100GB dataset/name
>
> That will reserve 100 GB of space for the dataset, and will make that
> space unavailable to the rest of the pool.
That doesn't make any sense to me ...
How does that allow "subversionuser" to use the space, and block "joeuser" from
using it?
_
> > zfs set reservation=100GB dataset/name
> >
> > That will reserve 100 GB of space for the dataset, and will make that
> > space unavailable to the rest of the pool.
>
> That doesn't make any sense to me ...
>
> How does that allow "subversionuser" to use the space, and block
> "joeuser" from u
> > Which is why ZFS isn't a replacement for proper array controllers
> (defining proper as those with sufficient battery to leave you with a
> seemingly intact filesystem), but a very nice augmentation for them. ;)
>
> Nothing prevents a clever chap from building a ZFS-based array
> controller
>
rable.
From: Brandon High [mailto:bh...@freaks.com]
Sent: Wednesday, March 24, 2010 2:33 PM
To: Edward Ned Harvey
Cc: Freddie Cash; zfs-discuss
Subject: Re: [zfs-discuss] To reserve space
On Wed, Mar 24, 2010 at 11:18 AM, Edward Ned Harvey
wrote:
Out of curiosity, the more general sol
> > I think the point is to say: ZFS software raid is both faster and
> more
> > reliable than your hardware raid. Surprising though it may be for a
> > newcomer, I have statistics to back that up,
>
> Can you share it?
Sure. Just go to http://nedharvey.com and you'll see four links on the lef
> The bigger problem is that you have to script around a disk failure, as
> the array won't bring a non-redundant logicaldrive back online after a
> disk failure without being kicked (which is a good thing in general,
> but
> annoying for ZFS).
I'd like to follow up on that point. Because until r
> Sorry if this has been dicussed before. I tried searching but I
> couldn't find any info about it. We would like to export our ZFS
> configurations in case we need to import the pool onto another box. We
> do not want to backup the actual data in the zfs pool, that is already
> handled through an
> Using fewer than 4 disks in a raidz2 defeats the purpose of raidz2, as
> you will always be in a degraded mode.
Freddie, are you nuts? This is false.
Sure you can use raidz2 with 3 disks in it. But it does seem pointless to do
that instead of a 3-way mirror.
_
> Coolio. Learn something new everyday. One more way that raidz is
> different from RAID5/6/etc.
Freddie, again, you're wrong. Yes, it's perfectly acceptable to create either
raid-5 or raidz using 2 disks. It's not degraded, but it does seem pointless
to do this instead of a mirror.
Likewis
Just because most people are probably too lazy to click the link, I’ll paste a
phrase from that sun.com webpage below:
“Creating a single-parity RAID-Z pool is identical to creating a mirrored pool,
except that the ‘raidz’ or ‘raidz1’ keyword is used instead of ‘mirror’.”
And
“zpool create tan
> OK, I have 3Ware looking into a driver for my cards (3ware 9500S-8) as
> I dont see an OpenSolaris driver for them.
>
> But this leads me that they do have a FreeBSD Driver, so I could still
> use ZFS.
>
> What does everyone thing about that? I bet it is not as mature as on
> OpenSolaris.
"mat
> It seems like the zpool export will ques the drives and mark the pool
> as exported. This would be good if we wanted to move the pool at that
> time but we are thinking of a disaster recovery scenario. It would be
> nice to export just the config to where if our controller dies, we can
> use the
> In the "Thoughts on ZFS Pool Backup Strategies thread" it was stated
> that zfs send, sends uncompress data and uses the ARC.
>
> If "zfs send" sends uncompress data which has already been compress
> this is not very efficient, and it would be *nice* to see it send the
> original compress data.
> While I use zfs with FreeBSD (FreeNAS appliance with 4x SATA 1 TByte
> drives)
> it is trailing OpenSolaris by at least a year if not longer and hence
> lacks
> many key features people pick zfs over other file systems. The
> performance,
> especially CIFS is quite lacking. Purportedly (I have ne
> >> You can't share a device (either as ZIL or L2ARC) between multiple
> pools.
> >
> > Discussion here some weeks ago reached suggested that an L2ARC device
> > was used for all ARC evictions, regardless of the pool.
> >
> > I'd very much like an authoritative statement (and corresponding
> > doc
> when I tried to create a pool (called group) with four 1TB disk in
> raidz and two 500GB disk in mirror configuration to the same pool ZFS
> complained and said if I wanted to do it I had to add a -f
Honestly, I'm surprised by that. I would think it's ok. I am surprised by
the -f, just as you
> On Mon, Mar 29, 2010 at 5:39 PM, Nicolas Williams
> wrote:
> > One really good use for zfs diff would be: as a way to index zfs send
> > backups by contents.
>
> Or to generate the list of files for incremental backups via NetBackup
> or similar. This is especially important for file systems w
If you "zfs export" it will offline your pool. This is what you do when
you're going to intentionally remove disks from the live system.
If you suffered a hardware problem, and you're migrating your
uncleanly-unmounted disks to another system, then as Brandon described
below, you'll need the "
> But the speedup of disabling the ZIL altogether is
> appealing (and would
> probably be acceptable in this environment).
Just to make sure you know ... if you disable the ZIL altogether, and you
have a power interruption, failed cpu, or kernel halt, then you're likely to
have a corrupt unusable
> standard ZIL: 7m40s (ZFS default)
> 1x SSD ZIL: 4m07s (Flash Accelerator F20)
> 2x SSD ZIL: 2m42s (Flash Accelerator F20)
> 2x SSD mirrored ZIL: 3m59s (Flash Accelerator F20)
> 3x SSD ZIL: 2m47s (Flash Accelerator F20)
> 4x S
> The problem that I have now is that each created snapshot is always
> equal to zero... zfs just not storing changes that I have made to the
> file system before making a snapshot.
>
> r...@sl-node01:~# zfs list
> NAME USED AVAIL REFER MOUNTPOINT
> mypool01
> Again, we can't get a straight answer on this one..
> (or at least not 1 straight answer...)
>
> Since the ZIL logs are committed atomically they are either committed
> in FULL, or NOT at all (by way of rollback of incomplete ZIL applies at
> zpool mount time / or transaction rollbacks if th
> Anyway, my question is, [...]
> as expected I can't import it because the pool was created
> with a newer version of ZFS. What options are there to import?
I'm quite sure there is no option to import or receive or downgrade a zfs
filesystem from a later version. I'm pretty sure your only option
> If the ZIL device goes away then zfs might refuse to use the pool
> without user affirmation (due to potential loss of uncommitted
> transactions), but if the dedicated ZIL device is gone, zfs will use
> disks in the main pool for the ZIL.
>
> This has been clarified before on the list by top zf
> So you think it would be ok to shutdown, physically remove the log
> device,
> and then power back on again, and force import the pool? So although
> there
> may be no "live" way to remove a log device from a pool, it might still
> be
> possible if you offline the pool to ensure writes are all c
> > Just to make sure you know ... if you disable the ZIL altogether, and
> you
> > have a power interruption, failed cpu, or kernel halt, then you're
> likely to
> > have a corrupt unusable zpool, or at least data corruption. If that
> is
> > indeed acceptable to you, go nuts. ;-)
>
> I believe
> Use something other than Open/Solaris with ZFS as an NFS server? :)
>
> I don't think you'll find the performance you paid for with ZFS and
> Solaris at this time. I've been trying to more than a year, and
> watching dozens, if not hundreds of threads.
> Getting half-ways decent performance fro
> > Nobody knows any way for me to remove my unmirrored
> > log device. Nobody knows any way for me to add a mirror to it (until
>
> Since snv_125 you can remove log devices. See
> http://bugs.opensolaris.org/view_bug.do?bug_id=6574286
>
> I've used this all the time during my testing and was ab
> >Oh, one more comment. If you don't mirror your ZIL, and your
> unmirrored SSD
> >goes bad, you lose your whole pool. Or at least suffer data
> corruption.
>
> Hmmm, I thought that in that case ZFS reverts to the "regular on disks"
> ZIL?
I see the source for some confusion. On the ZFS Best Pr
> Would your users be concerned if there was a possibility that
> after extracting a 50 MB tarball that files are incomplete, whole
> subdirectories are missing, or file permissions are incorrect?
Correction: "Would your users be concerned if there was a possibility that
after extracting a 50MB t
> I did those test and here are results:
>
> r...@sl-node01:~# zfs list
> NAMEUSED AVAIL REFER MOUNTPOINT
> mypool01 91.9G 136G23K /mypool01
> mypool01/storage01 91.9G 136G 91.7G /mypool01/storage01
> mypool01/storag...@30
> I see the source for some confusion. On the ZFS Best Practices page:
> http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
>
> It says:
> Failure of the log device may cause the storage pool to be inaccessible
> if
> you are running the Solaris Nevada release prior to build
> A MegaRAID card with write-back cache? It should also be cheaper than
> the F20.
I haven't posted results yet, but I just finished a few weeks of extensive
benchmarking various configurations. I can say this:
WriteBack cache is much faster than "naked" disks, but if you can buy an SSD
or two f
> 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 drives arriving f
> >If you disable the ZIL, the filesystem still stays correct in RAM, and
> the
> >only way you lose any data such as you've described, is to have an
> >ungraceful power down or reboot.
>
> >The advice I would give is: Do zfs autosnapshots frequently (say ...
> every
> >5 minutes, keeping the mos
> > Can you elaborate? Just today, we got the replacement drive that has
> > precisely the right version of firmware and everything. Still, when
> we
> > plugged in that drive, and "create simple volume" in the storagetek
> raid
> > utility, the new drive is 0.001 Gb smaller than the old drive.
> >If you have an ungraceful shutdown in the middle of writing stuff,
> while the
> >ZIL is disabled, then you have corrupt data. Could be files that are
> >partially written. Could be wrong permissions or attributes on files.
> >Could be missing files or directories. Or some other problem.
> >
> This approach does not solve the problem. When you do a snapshot,
> the txg is committed. If you wish to reduce the exposure to loss of
> sync data and run with ZIL disabled, then you can change the txg commit
> interval -- however changing the txg commit interval will not eliminate
> the
> pos
> Is that what "sync" means in Linux?
A sync write is one in which the application blocks until the OS acks that
the write has been committed to disk. An async write is given to the OS,
and the OS is permitted to buffer the write to disk at its own discretion.
Meaning the async write function c
> On opensolaris? Did you try deleting any old BEs?
Don't forget to "zfs destroy rp...@snapshot"
In fact, you might start with destroying snapshots ... if there are any
occupying space.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://ma
> > Seriously, all disks configured WriteThrough (spindle and SSD disks
> > alike)
> > using the dedicated ZIL SSD device, very noticeably faster than
> > enabling the
> > WriteBack.
>
> What do you get with both SSD ZIL and WriteBack disks enabled?
>
> I mean if you have both why not use both? T
> I know it is way after the fact, but I find it best to coerce each
> drive down to the whole GB boundary using format (create Solaris
> partition just up to the boundary). Then if you ever get a drive a
> little smaller it still should fit.
It seems like it should be unnecessary. It seems like
> > http://nfs.sourceforge.net/
>
> I think B4 is the answer to Casper's question:
We were talking about ZFS, and under what circumstances data is flushed to
disk, in what way "sync" and "async" writes are handled by the OS, and what
happens if you disable ZIL and lose power to your system.
We w
> > I am envisioning a database, which issues a small sync write,
> followed by a
> > larger async write. Since the sync write is small, the OS would
> prefer to
> > defer the write and aggregate into a larger block. So the
> possibility of
> > the later async write being committed to disk before
> hello
>
> i have had this problem this week. our zil ssd died (apt slc ssd 16gb).
> because we had no spare drive in stock, we ignored it.
>
> then we decided to update our nexenta 3 alpha to beta, exported the
> pool and made a fresh install to have a clean system and tried to
> import the poo
> ZFS recovers to a crash-consistent state, even without the slog,
> meaning it recovers to some state through which the filesystem passed
> in the seconds leading up to the crash. This isn't what UFS or XFS
> do.
>
> The on-disk log (slog or otherwise), if I understand right, can
> actually make
> If you have zpool less than version 19 (when ability to remove log
> device
> was introduced) and you have a non-mirrored log device that failed, you
> had
> better treat the situation as an emergency.
> Instead, do "man zpool" and look for "zpool
> remove."
> If it says "supports removing log
> >Dude, don't be so arrogant. Acting like you know what I'm talking
> about
> >better than I do. Face it that you have something to learn here.
>
> You may say that, but then you post this:
Acknowledged. I read something arrogant, and I replied even more arrogant.
That was dumb of me.
__
> Only a broken application uses sync writes
> sometimes, and async writes at other times.
Suppose there is a virtual machine, with virtual processes inside it. Some
virtual process issues a sync write to the virtual OS, meanwhile another
virtual process issues an async write. Then the virtual O
> 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
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
> > 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,
> >
>> 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
> 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
>
> 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
1 - 100 of 1156 matches
Mail list logo
