Re: [zfs-macos] Speed Tests

Is my understanding correct that you can't "fix" a pool after it's been created, but you actually have to create a new pool with the optimal settings of the day, and copy data around to get performance improvements? That doesn't sound right. On Sun, Mar 9, 2014 at 6:43 AM, Jason Belec wrote: >

Re: [zfs-macos] Speed Tests

dual pool creation. Those coming from ZEVO may have > significantly different experience. ;) > > Jason > Sent from my iPhone 5S > > On Mar 9, 2014, at 5:47 PM, Daniel wrote: > > Is my understanding correct that you can't "fix" a pool after it's been > cre

Re: [zfs-macos] Re: Transferring from 10.8.4/ZEVO to 10.9/macZFS?

By default, creating a zvol will reserve space equal to its volume size. You can avoid that by passing “-s” to the zfs create command; however, note that the amount of space left in the parent will not be passed through to whatever FS you create on the zvol, so bad things happen when the parent

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

A few things to think about when reading that forum post: - The scenario described in that post is based on the assumption that all blocks read from disk somehow get funneled through a single memory location, which also happens to have a permanent fault. - In addition, it assumes that after a ch

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

:09 PM, Daniel Becker wrote: > A few things to think about when reading that forum post: > > - The scenario described in that post is based on the assumption that all > blocks read from disk somehow get funneled through a single memory location, > which also happens to have a pe

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

Incidentally, that paper came up in a ZFS-related thread on Ars Technica just the other day (as did the link to the FreeNAS forum post). Let me just quote what I said there: > The conclusion of the paper is that ZFS does not protect against in-memory > corruption, and thus can't provide end-to-

[zfs-macos] What's zpool version 5000?!

Hey ppl ;) I've been wondering about "version 5000", and what it signifies. Does this bump mean a fork from Oracle's code? Will there be a 5001, 5002, 5099, etc. in the future, on a path separate and incompatible from Oracle's versions? Or is it just some kind of nonsense number, like setting Sam

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

Wouldn't ZFS actually make things better as opposed to worse? Say I have a Macbook with failing memory, and there's a magnetic storm. If I was using HFS+, with each write I'd be seeding the drive with bit errors, without ever noticing until the system crashes. If the bit error happens infrequen

Re: [zfs-macos] Is it ok to discuss OpenZFS/ZFS-OSX here?

On Friday, 28 February 2014, 3:49, Robert Rehnmark wrote: Is it ok to discuss OpenZFS/ZFS-OSX here? > >I joined to IRC channel but when panicking and posting logs/screendumps I >guess IRC isn't very practical. > >Hey there Robert.  It's called the MacZFS prototype, hopefully soon to be >beta

Re: [zfs-macos] Is it ok to discuss OpenZFS/ZFS-OSX here?

There has been no activity on that mailing list in about 3 months! I'd say this is an indication that MacZFS was dead dead dead, were it not for the apparently frequent check-ins to Github. Can anyone enlighten me what exactly is happening to this list? Is there a new and better channel of comms

[zfs-macos] Re: Raid10 HFS+ perfomance much faster then ZFS

I don't remember anyone ever saying that ZFS was fast. In fact it's a resource hog, and quite cumbersome. It is flexible and safe. Your test is equivalent to saying that it's much easier to walk around with money in a paper bag than in a reinforced steel security carrier case. (BTW, speaking of

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

On Mar 2, 2014, at 12:45 AM, Philip Robar wrote: > But if you insist: from "Oracle Solaris 11.1 Administration: ZFS File > Systems", "Consider using ECC memory to protect against memory corruption. > Silent memory corruption can potentially damage your data." [1] That is in no way specific to

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

On Mar 2, 2014, at 2:33 AM, Bjoern Kahl wrote: > On the other side you say (only) 8% of all DIMMs are affected per > *year*. I *guess* (and might be wrong) that the majority of installed > DIMMs nowadays are 2 GB DIMMs, so you need four of them to build > 8 GB. Assuming equal distribution of bi

Re: [zfs-macos] Re: Raid10 HFS+ perfomance much faster then ZFS

Roman, did you create your zpool with ashift=12 on a 4k drive?  You must manually ascertain whether your drives are 4k because they'll usually lie and be really slow. On Tuesday, 4 March 2014, 11:11, Daniel Jozsef wrote: I don't remember anyone ever saying that ZFS was fast. In f

Re: [zfs-macos] Is it ok to discuss OpenZFS/ZFS-OSX here?

That's cool. It would have been a shame if after ZEVO, OpenZFS for Mac went under as well. On Sunday, March 2, 2014 6:27:42 AM UTC-5, Jorgen Lundman wrote: > > I'm still working, doing code. Plenty people helping. I want to get a > ReleaseCandidate installer out this week. Plenty distractions go

Re: [zfs-macos] Re: Speed Tests

On Mar 15, 2014, at 6:58 AM, jazzsmoothies wrote: > Also, is there a difference between normalization=formD at the pool vs > directory level? Creating a zpool always implies creating its root fs (which has the same name as the pool) as well. Any -O options you pass to zpool create are effectiv

Re: [zfs-macos] pros/cons of multiple zfs filesystems

On Mar 18, 2014, at 4:52 AM, roemer wrote: > I am also not sure now whether the performance is still higher due to > parallel I/O (see comment above about constant number of disk ops per > RAIDZ)... > At least it should be so high to saturate a gigabit ethernet link (i.e. 100 - > 110 MB/s). F

Re: [zfs-macos] Re: pros/cons of multiple zfs filesystems

*Finder *is one of them. When I first migrated my Linux-created ZFS mirror pool over to ZEVO (after tearing down my NAS box, and housing my data in a pair of simple Firewire 800 enclosures), I noticed that files that were there in the command line were missing in Finder. Sometimes Finder would

Re: [zfs-macos] Re: ZFS w/o ECC RAM -> Total loss of data

On Mar 31, 2014, at 2:23 PM, Eric Jaw wrote: > Doing a scrub is just obliterating my pool. Is it? I don’t think so: > scan: scrub in progress since Mon Mar 31 10:14:52 2014 > 1.83T scanned out of 2.43T at 75.2M/s, 2h17m to go > 0 repaired, 75.55% done Note the “0 repaired.” >

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

On Mar 31, 2014, at 7:41 PM, Eric Jaw wrote: > I started using ZFS about a few weeks ago, so a lot of it is still new to me. > I'm actually not completely certain about "proper procedure" for repairing a > pool. I'm not sure if I'm supposed to clear the errors after the scrub, > before or afte

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

t;>>>> >>>>> >>>>> My oldest system running ZFS is an Mac Mini Intel Core Duo with 3GB RAM >>>>> (not ECC) it is the home server for music, tv shows, movies, and some >>>>> interim backups. The mini has been modded for ESATA a

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

t;>>>> interim backups. The mini has been modded for ESATA and has 6 drives >>>>>> connected. The pool is 2 RaidZ of 3 mirrored with copies set at 2. Been >>>>>> running since ZFS was released from Apple builds. Lost 3 drives, >>>>>&g

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

On Apr 2, 2014, at 3:08 PM, Matt Elliott wrote: > Not true. ZFS flushes also mark known states. If the zfs stack issues a > flush and the system returns, it uses that as a guarantee that that data is > now on disk. However, that guarantee is only needed to ensure that on-disk data is consis

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

So to summarize that article, "using ECC memory is safer than not using ECC memory." I don't think this was ever in doubt. Note that he does *not* talk about anything like the hypothetical "a scrub will corrupt all your data" scenario (nor is anything like that mentioned in his popular "ZFS: Read M

Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data

You know, you remind me of my Computer Architectures lecturer. Considered a weird guy university-wide, he had these funny maxims like "a PC is not a computer" and "Windows is not an Operating System". Back then, I kind of saw what he meant, but the funny part is that nowadays, it's as if his sc

Re: [zfs-macos] RAIDZ1 running slow =(

How much memory do you have on that machine, if you're running ZFS and VMs? > On May 18, 2014, at 5:27 PM, James Hoyt wrote: > > So I setup a MacZFS RaidZ rather easily and was happy with myself. I had four > 3 TB internal SATA drives in a zpool giving me around 9 TB of space. > > jamess-imac:

Re: [zfs-macos] RAIDZ1 running slow =(

nity as a whole. Daniel On Tue, May 20, 2014 at 9:59 AM, James Hoyt wrote: > I did status as you can see from my original post.. I didn't know > scrub and clean. I did my research only on MacZFS because I thought > that's only where it mattered. I didn't trust info on

Re: [zfs-macos] Weird I/O block

Based on what you posted earlier, you’re still seeing lots of read and write errors after replacing the cables, so I highly doubt those were really the root of your problem. > On Nov 18, 2014, at 12:23 PM, Anders Wallén wrote: > > The arrays are housed in cabinets of this type >

Re: [zfs-macos] Weird I/O block

Can you try connecting these to a different machine, and/or via either eSATA or USB 2.0? > On Nov 18, 2014, at 12:37 PM, Daniel Becker wrote: > > Based on what you posted earlier, you’re still seeing lots of read and write > errors after replacing the cables, so I highly doub

Re: [zfs-macos] Weird I/O block

issues with ZFS. > On Nov 18, 2014, at 12:39 PM, Daniel Becker wrote: > > Can you try connecting these to a different machine, and/or via either eSATA > or USB 2.0? > > >> On Nov 18, 2014, at 12:37 PM, Daniel Becker > <mailto:razzf...@gmail.com>> wr