Re: selectively disabling atime updates?
On Thu, May 31, 2012 at 08:37:06AM -0700, Paul Goyette wrote: On Thu, 31 May 2012, Matthias Kretschmer wrote: On Thu, May 31, 2012 at 04:42:27PM +0200, Edgar Fuß wrote: How about using fss for it instead. 1. fss is still marked experimental. oh, I have overlooked that. 2. does fss work with WAPL at all? I don't know that. It seems to work for me! All my FS are WAPBL-enabled, and I always use backup -X for snapshot. rsync from a snapshot wouldn't work for me on sparc-64 with an oldish kernel (5.99.something). I must setup one of the slower machines for at least partial tests, because the main one is the file server... Paul, what's your architecture and version? -is -- seal your e-mail: http://www.gnupg.org/
Re: selectively disabling atime updates?
On Thu, May 31, 2012 at 04:56:26PM +0200, Matthias Kretschmer wrote: How about using fss for it instead. 1. fss is still marked experimental. oh, I have overlooked that. I'm not sure that should stop you though. Or the marking should be removed. People use it, it seems to work, it's been a while since anyone's reported problems that I've noticed. 2. does fss work with WAPL at all? I don't know that. It's expected to at this point. (In -6 and -current, but IIRC not in -5.) -- David A. Holland dholl...@netbsd.org
Re: selectively disabling atime updates?
How about using fss for it instead. Well, the point is not that I primarily don't want the atimes to reflect the backup access. I primarily want to save the time spent on the update. A find is aproximately twice as fast with noatime.
Re: selectively disabling atime updates?
On Fri, 1 Jun 2012, Ignatios Souvatzis wrote: How about using fss for it instead. 1. fss is still marked experimental. oh, I have overlooked that. 2. does fss work with WAPL at all? I don't know that. It seems to work for me! All my FS are WAPBL-enabled, and I always use backup -X for snapshot. rsync from a snapshot wouldn't work for me on sparc-64 with an oldish kernel (5.99.something). I must setup one of the slower machines for at least partial tests, because the main one is the file server... Paul, what's your architecture and version? I'm completely amd64 here, and currently running 6.99.5 - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Rump FS throughput
On Thu, May 31, 2012 at 01:45:53PM -0400, Matthew Mondor wrote: Although it's useful to mount random media more safely than it would be using kernel-space, I noticed that using 64KB reads, the kernel cd9660 will gladly read ~20MB/s from a DVD, but that rump_cd9660 using 64KB reads is limited to aproximately 4MB/s at most, even if the system is mostly idle during those transfers (on netbsd-6/amd64 and 4 3.3GHz cores). Some suggestions from Antti via email proxy: Maybe he is using the block device (/dev/cd0a) instead of the raw device (/dev/rcd0a). IIRC the former has some pretty serious performance problems for userspace I/O. Also in the maybe department, libp2k should probably detect and autoadjust a block device to raw device. Or, someone could just fix the bdev stuff. Cheers, Thomas
