Date: Fri, 29 Apr 2011 12:21:18 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable List <freebsd-stable@freebsd.org> Subject: Re: ZFS vs OSX Time Machine Message-ID: <B8C26D25-F156-46E5-89DD-EF3931F111BC@gsoft.com.au> In-Reply-To: <20110429010829.GA36744@icarus.home.lan> References: <537A8F4F-A302-40F9-92DF-403388D99B4B@gsoft.com.au> <20110428195601.GA31807@icarus.home.lan> <AF725CFF-86A4-4D65-A26E-496F6B9BD33E@gsoft.com.au> <20110429010829.GA36744@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29/04/2011, at 10:38, Jeremy Chadwick wrote: > Could you please provide output from "zfs get all poolname"? Myself = and > others would like to review what settings you're using on the > filesystem. If it's a separate filesystem (e.g. pool/foobar), please > also provide output from "zfs get all pool". [midget 11:51] ~ >zfs get all tank NAME PROPERTY VALUE SOURCE tank type filesystem - tank creation Thu Sep 24 11:22 2009 - tank used 2.58T - tank available 981G - tank referenced 44.7K - tank compressratio 1.00x - tank mounted yes - tank quota none default tank reservation none default tank recordsize 128K default tank mountpoint /tank default tank sharenfs off default tank checksum on default tank compression off default tank atime on default tank devices on default tank exec on default tank setuid on default tank readonly off default tank jailed off default tank snapdir hidden default tank aclmode groupmask default tank aclinherit restricted default tank canmount on default tank shareiscsi off default tank xattr off temporary tank copies 1 default tank version 3 - tank utf8only off - tank normalization none - tank casesensitivity sensitive - tank vscan off default tank nbmand off default tank sharesmb off default tank refquota none default tank refreservation none default tank primarycache all default tank secondarycache all default tank usedbysnapshots 0 - tank usedbydataset 44.7K - tank usedbychildren 2.58T - tank usedbyrefreservation 0 - [midget 11:51] ~ >zfs get all tank/TimeMachine =20 NAME PROPERTY VALUE SOURCE tank/TimeMachine type filesystem - tank/TimeMachine creation Sat May 8 10:59 2010 - tank/TimeMachine used 555G - tank/TimeMachine available 45.3G - tank/TimeMachine referenced 555G - tank/TimeMachine compressratio 1.00x - tank/TimeMachine mounted yes - tank/TimeMachine quota 600G local tank/TimeMachine reservation none default tank/TimeMachine recordsize 128K default tank/TimeMachine mountpoint /tank/TimeMachine default tank/TimeMachine sharenfs off default tank/TimeMachine checksum on default tank/TimeMachine compression off default tank/TimeMachine atime on default tank/TimeMachine devices on default tank/TimeMachine exec on default tank/TimeMachine setuid on default tank/TimeMachine readonly off default tank/TimeMachine jailed off default tank/TimeMachine snapdir hidden default tank/TimeMachine aclmode groupmask default tank/TimeMachine aclinherit restricted default tank/TimeMachine canmount on default tank/TimeMachine shareiscsi off default tank/TimeMachine xattr off temporary tank/TimeMachine copies 1 default tank/TimeMachine version 3 - tank/TimeMachine utf8only off - tank/TimeMachine normalization none - tank/TimeMachine casesensitivity sensitive - tank/TimeMachine vscan off default tank/TimeMachine nbmand off default tank/TimeMachine sharesmb off default tank/TimeMachine refquota none default tank/TimeMachine refreservation none default tank/TimeMachine primarycache all default tank/TimeMachine secondarycache all default tank/TimeMachine usedbysnapshots 0 - tank/TimeMachine usedbydataset 555G - tank/TimeMachine usedbychildren 0 - tank/TimeMachine usedbyrefreservation 0 - >> The OSX box is connected via an Airport Express (11n). >=20 > Can you connect something to it via Ethernet and attempt an FTP = transfer > (both PUT (store on server) and GET (retrieve from server)) from a > client on the wired network? Make sure whatever you're PUT'ing and > GET'ing are using the ZFS filesystem. Don't forget "binary" mode too. I'll try that tonight. > You should see very good performance on files that are already in the > ARC. So for example, pick a 500MB ISO file that hasn't been accessed > previously (thus isn't in the ARC). GET'ing it should result in a lot > of disk I/O (zpool iostat -v 1). But a subsequent GET should show = very > little disk I/O, as all the data should be coming from memory (ARC). = A > PUT would test write. >=20 > Basically what I'm trying to figure out here is if the network layer = is > somehow causing these problems for you or not. Wireless is simply too > unreliable/too flippant in packet loss and latency to be a good medium > to test throughput of a filesystem. Period. I'll try but I would expect backup over wireless to cause less of a = performance degradation of other ZFS consumers because the backup is = being throttled by it. I am not concerned about the time it takes to do a time machine backup = since it happens in the background and in any case I believe OSX makes = it go slow to not hammer the machine being backed up. > Be aware there are all sorts of caveats/complexities with iSCSI on > FreeBSD. There are past threads on -stable and -fs talking about them > in great detail. I personally wouldn't go this route. OK. It also seems that OSX can't see iSCSI disks out of the box so I suspect = I would not be able to do a bare metal restore from one which greatly = limits the desirability of it. > Why can't OS X use CIFS? It has the ability to mount a SMB = filesystem, > right? Is there some reason you can't mount that, then tell TM to = write > its backups to /mountedcifs? I'm not sure.. You need to set a flag to allow it to backup to a "non = standard" (ie non TimeCapsule) AFS share. In any case I would still have to create a HFS+ volume on the CIFS = partition so I'm not sure it would make any practical difference (vs = AFP). >>> (please don't; it would be more useful if it could be kept up in = case >>> folks want to do analysis of it). >>=20 >> I think performance does improve after a reboot :( >=20 > This could be a memory performance or fragmentation problem then. = Gosh > it's been a long time since I've read about that. Some FreeBSD folks > knew of such, and I think someone came up with a patch for it, but I'm > not sure. I wish I could remember the name of the developer who was > talking about it. Artem Belevich maybe? OK.. It does act as a desktop box too which I imagine won't help any.. > The other problem a user had pertaining to ZFS and memory performance > was even more odd, but was eventually tracked down. He had installed > two DIMMs in his machine (making a total of 4) and suddenly memory > performance was abysmal. Remove the DIMMs, performance restored. Put > the two removed DIMMs in (previous working ones out), performance was Huh interesting :) > fine. If I remember right, the issue turned out to be a bug in the > BIOS, and a BIOS upgrade from Intel (it was an Intel motherboard) = fixed > it. Intel is one of the only companies that releases *very* concise = and > decent changelogs for their BIOSes, which is wonderful. Yes, most are opaque beyond belief.. Supermicro also label them MMDDYY just to minimise utility too.. >> although free does go down very low (~250MB) at times. >=20 > This is normal. The ZFS ARC has most of your memory (shown as "Wired" > in the above top output). If something needs memory, parts of the ARC > will be released/freed given memory pressure. OK. > I will note something, however: your ARC max is set to 3072MB, yet = Wired > is around 4143MB. Do you have something running on this box that = takes > up a lot of RAM? mysqld, etc..? I'm trying to account for the "extra > gigabyte" in Wired. "top -o res" might help here, but we'd need to = see > the process list. It runs X and so on which probably soak up a fair bit. It runs a very lightly loaded postgres as well. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8C26D25-F156-46E5-89DD-EF3931F111BC>