Re: [zfs-discuss] send/recv over ssh
Le 21 mai 10 à 02:44, Freddie Cash a écrit : On Thu, May 20, 2010 at 4:40 PM, Brent Jones wrote: On Thu, May 20, 2010 at 3:42 PM, Brandon High wrote: > On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess wrote: >> I know i'm probably doing something REALLY stupid.but for some reason i >> can't get send/recv to work over ssh. I just built a new media server and > > Unless you need to have the send to be encrypted, ssh is going to slow > you down a lot. > > I've used mbuffer when doing sends on the same network, it's worked well. > pre-start an Mbuffer session on the receiving end somehow. SSH is always running on the receiving end, so no issues there. And you can always patch OpenSSH with HPN, thus enabling the NONE cipher, which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. Without patching anything, using arcfour instead of the default cipher increase the transfer rate dramatically. It is bounded by the Gb/s network here, not by ssh. Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] compressed fs taking up more space than uncompressed equivalent
Le 23 oct. 09 à 08:46, Stathis Kamperis a écrit : 2009/10/23 michael schuster : Stathis Kamperis wrote: Salute. I have a filesystem where I store various source repositories (cvs + git). I have compression enabled on and zfs get compressratio reports 1.46x. When I copy all the stuff to another filesystem without compression, the data take up _less_ space (3.5GB vs 2.5GB). How's that possible ? just a few thoughts: - how do you measure how much space your data consumes? With zfs list, under the 'USED' column. du(1) gives the same results as well (the individual fs sizes aren't enterily identical with those that zfs list reports , but the difference still exists). tank/sources 3.73G 620G 3.73G /export/sources <--- compressed tank/test 2.32G 620G 2.32G /tank/test <--- uncompressed USED includes the size of the children and the size of the snapshot. I see below that you don't have snapshots on that pull, but in general, I found more useful to use zfs list -o space,compress,ratio to look at how the space is used. - how do you copy? With cp(1). Should I be using zfs send | zfs receive ? zfs send/receive or rsync -aH may do a better job by preserving hard links. Regards, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zfs improvements to compression in Solaris 10?
Le 4 août 09 à 20:25, Prabahar Jeyaram a écrit : On Tue, Aug 04, 2009 at 01:01:40PM -0500, Bob Friesenhahn wrote: On Tue, 4 Aug 2009, Prabahar Jeyaram wrote: You seem to be hitting : http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537 The fix is available in OpenSolaris build 115 and later not for Solaris 10 yet. It is interesting that this is a simple thread priority issue. The system has a ton of available CPU but the higher priority compression thread seems to cause scheduling lockout. The Perfmeter tool shows that compression is a very short-term spike in CPU. Of course since Perfmeter and other apps stop running, it might be missing some sample data. I could put the X11 server into the real-time scheduling class but hate to think about what would happen as soon as Firefox visits a web site. :-) Compression is only used for the intermittently-used backup pool so it would be a shame to reduce overall system performance for the rest of the time. Do you know if this fix is planned to be integrated into a future Solaris 10 update? Yes. It is planned for S10U9. In the mean time, is there a patch available for Solaris 10? I can't find it on sunsolve. Thanks, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs zend is very slow
Le 17 déc. 09 à 03:19, Brent Jones a écrit : Something must've changed in either SSH, or the ZFS receive bits to cause this, but sadly since I upgrade my pool, I cannot roll back these hosts :( I'm not sure that's the best way, but to look at how ssh is slowing down the transfer, I'm usually doing something like that: zfs send -R data/vo...@2009-12-14_01h44m47 | pv | ssh hex "cat > / dev/null" I usually get approximately 60 MB/s. Changing the cipher can enhance the transfer rate noticeably: "-c arcfour" gives an extra 10 MB/s here. If you found that ssh is what is slowing down the transfer, maybe another cipher than the default one can help. Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] directory size on compressed file system on Solaris 10
Hi, On opensolaris, I use du with the -b option to get the uncompressed size of a directory): r...@opensolaris:~# du -sh /usr/local/ 399M/usr/local/ r...@opensolaris:~# du -sbh /usr/local/ 915M/usr/local/ r...@opensolaris:~# zfs list -o space,refer,ratio,compress data/local NAMEAVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD REFER RATIO COMPRESS data/local 228G 643M 249M394M 0 0 394M 2.51xon r...@opensolaris:~# which du /usr/gnu/bin/du but on Solaris 10, there is no such option. So what is the best way to get the uncompressed size of a directory on Solaris 10? Regards, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] directory size on compressed file system on Solaris 10
Le 21 déc. 09 à 19:28, Matthew Ahrens a écrit : Gaëtan Lehmann wrote: Hi, On opensolaris, I use du with the -b option to get the uncompressed size of a directory): r...@opensolaris:~# du -sh /usr/local/ 399M/usr/local/ r...@opensolaris:~# du -sbh /usr/local/ 915M/usr/local/ r...@opensolaris:~# zfs list -o space,refer,ratio,compress data/ local NAMEAVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD REFER RATIO COMPRESS data/local 228G 643M 249M394M 0 0 394M 2.51xon r...@opensolaris:~# which du /usr/gnu/bin/du but on Solaris 10, there is no such option. So what is the best way to get the uncompressed size of a directory on Solaris 10? Install GNU du on solaris 10? That's an option of course, but I'd prefer something that I can use installing any extra program. Although the answer will be just as (in)accurate as GNU du on solaris 10. Note that it reports the compression ratio as 915/399 = 2.29x, actual is 2.51x. This could be due to sparse files, or metadata like directories, whose "apparent size" (st_size) is not what GNU du expects. At least it gives a not so bad estimation :-) And the compression ratio includes the data in the snapshots, so it may be inaccurate in that case also. The actual compression ratio, given on the last snapshot, is 2.41x. Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] directory size on compressed file system on Solaris 10
Le 21 déc. 09 à 20:23, Joerg Schilling a écrit :
Matthew Ahrens wrote:
Gaëtan Lehmann wrote:
Hi,
On opensolaris, I use du with the -b option to get the
uncompressed size
of a directory):
r...@opensolaris:~# du -sh /usr/local/
399M/usr/local/
r...@opensolaris:~# du -sbh /usr/local/
915M/usr/local/
r...@opensolaris:~# zfs list -o space,refer,ratio,compress data/
local
NAMEAVAIL USED USEDSNAP USEDDS USEDREFRESERV
USEDCHILD
REFER RATIO COMPRESS
data/local 228G 643M 249M394M
0 0
394M 2.51xon
r...@opensolaris:~# which du
/usr/gnu/bin/du
but on Solaris 10, there is no such option.
So what is the best way to get the uncompressed size of a
directory on
Solaris 10?
Install GNU du on solaris 10? Although the answer will be just as
(in)accurate as GNU du on solaris 10. Note that it reports the
compression
How about:
find . -type f -ls | awk '{ sum += $7} END {print sum}'
sounds good
r...@opensolaris:~# find /usr/local/ -ls | awk '{sum += $7} END
{print sum/1024**2}'
914.039
but maybe a little longer to write
r...@opensolaris:~# echo "du -sbh ." | wc -c
10
r...@opensolaris:~# echo "find . -ls | awk '{sum += $7} END {print
sum/1024**2}'" | wc -c
53
Thanks!
Gaëtan
--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66fax: 01 34 65 29 09
http://voxel.jouy.inra.fr http://www.itk.org
http://www.mandriva.org http://www.bepo.fr
PGP.sig
Description: Ceci est une signature électronique PGP
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Backing up a ZFS pool
Le 17 janv. 10 à 11:38, Edward Ned Harvey a écrit : Personally, I use "zfs send | zfs receive" to an external disk. Initially a full image, and later incrementals. Do these incrementals go into the same filesystem that received the original zfs stream? Yes. In fact, I think that's the only way possible. The end result is ... On my external disk, I have a ZFS filesystem, with snapshots. Each snapshot corresponds to each incremental send| receive. Personally, I like to start with a fresh "full" image once a month, and then do daily incrementals for the rest of the month. There is one drawback: If I have >500G filesystem to backup, and I have 1Tb target media ... Once per month, I have to "zpool destroy" the target media before I can write a new full backup onto it. This leaves a gap where the backup has been destroyed and the new image has yet to be written. To solve this problem, I have more than one external disk, and occasionally rotate them. So there's still another offline backup available, if something were to happen to my system during the moment when the backup was being destroyed once per month. ZFS can check the pool and make sure that there is no error. Running 'zpool scrub' on the two pools from time to time - let's say every month - should give you a similar level of protection without the need for a full backup. Even when backing up with rsync+zfs snapshot, a full incremental every month may not be required. A rsync run with the --checksum option every month may be good enough. It forces the read of the full data on both sides, but at least it avoids the network transfer if the pools are on different hosts, and it avoids increasing the space used by the snapshots. Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Backing up a ZFS pool
Le 18 janv. 10 à 09:24, Edward Ned Harvey a écrit : Personally, I like to start with a fresh "full" image once a month, and then do daily incrementals for the rest of the month. This doesn't buy you anything. ZFS isn't like traditional backups. If you never send another full, then eventually the delta from the original to the present will become large. Not a problem, you're correct, as long as your destination media is sufficiently large. Unless I am mistaken, I believe, the following is not possible: On the source, create snapshot "1" Send snapshot "1" to destination On the source, create snapshot "2" Send incremental, from "1" to "2" to the destination. On the source, destroy snapshot "1" On the destination, destroy snapshot "1" I think, since snapshot "2" was derived from "1" you can't destroy "1" unless you've already destroyed "2" This is definitely possible with zfs. Just try! Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zones and other filesystems
Le 21 janv. 10 à 12:33, Thomas Burgess a écrit : I'm pretty new to opensolaris. I come from FreeBSD. Naturally, after using FreeBSD forr awhile i've been big on the use of FreeBSD jails so i just had to try zones. I've figured out how to get zones running but now i'm stuck and need help. Is there anything like "nullfs" in opensolaris... or maybe there is a more "solaris" way of doing what i need to do. Basically, what i'd like to do is give a specific zone access to 2 zfs filesystems which are available to the global zone. my new zones are in: /export/home/zone1 /export/home/zone2 the path of the root of your zone is not important for that feature. What i'd like to do is give them access to: /tank/nas/Video /tank/nas/JeffB with zonecfg, you can add a configuration like this one to your zone: add fs set dir=/some/path/Video set special=/tank/nas/Video set type=lofs end add fs set dir=/some/path/JeffB set special=/tank/nas/JeffB set type=lofs end Your filesystems will appear in /some/path/Video and /some/path/JeffB in your zone, and still be accessible in the global zone. http://docs.sun.com/app/docs/doc/817-1592/z.conf.start-29?a=view This option don't let you manage the filesystems from the zone though. You must use "add dataset" in that case. http://docs.sun.com/app/docs/doc/819-5461/gbbst?a=view Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zones and other filesystems
Le 21 janv. 10 à 14:14, Thomas Burgess a écrit : now i'm stuck again.sorry to clog the tubes with my nubishness. i can't seem to create users inside the zonei'm sure it's due to zfs privelages somewhere but i'm not exactly sure how to fix iti dont' mind if i need to manage the zfs filesystem outside of the zone, i'm just not sure WHERE i'm supposed to do it when i try to create a home dir i get this: mkdir: Failed to make directory "wonslung"; Operation not applicable when i try to do it via adduser i get this: UX: useradd: ERROR: Unable to create the home directory: Operation not applicable. and when i try to enter the zone home dir from the global zone i get this, even as root: bash: cd: home: Not owner have i seriously screwed up or did i again miss something vital. Maybe it's because of the automounter. If you don't need that feature, try to disable it in your zone with svcadm disable autofs Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Wrice cache for compressed file system
Hi, I'd like to compress quite well compressable (~4x) data on a file server using ZFS compression, and still get good transfer speed. The users are transferring several GB of data (typically, 8-10 GB). The host is a X4150 with 16 GB of RAM. Looking at ZFS layer described at http://www.opensolaris.org/os/community/zfs/source/ , it seems that the ZIL can play this role, as it is able to store the data uncompressed on a disk before passing the data to ZIO for the compression and the transfer to the final drives. Fortunately, I got two idle drives in the server that I can use as log devices for my data pool. Unfortunately, it has no effect on write performances, so I guess I was wrong in thinking that the ZIL can cache the data before compression. So is it possible to use the ZIL cache the data before compression? Did I miss an option somewhere? Thanks! Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Wrice cache for compressed file system
Hi Darren, Le 7 juil. 09 à 13:41, Darren J Moffat a écrit : Gaëtan Lehmann wrote: I'd like to compress quite well compressable (~4x) data on a file server using ZFS compression, and still get good transfer speed. The users are transferring several GB of data (typically, 8-10 GB). The host is a X4150 with 16 GB of RAM. What protocol is being used for file transfer ? FTP, sftp, NFSv3, NFSv4, CIFS/SMB, iSCSI, FCoE, other ? There will be two kinds of transfer protocol, once in production - CIFS and one specific to the application. But for a quick test, the test was made with scp. It is really important to know that. Also really important is what the data access pattern is ? Is it read mostly or write mostly ? Are the files that are written accessed for read soon ? Is it sequential or random reads ? It is read mostly. Files are usually rarely accessed, but are likely to be accessed several times when they begin to be accessed. This is sequential read. The data set is transfered on the server, and the files are not modified after that (or very rarely). The whole data set is transfered at once. What is "good" by your definition ? The data set is transfered in a little less than 3 minutes without compression - that's good! With compression, the data set is transfered in 15 minutes. I was hopping that a disk write cache can keep the transfer speed close to the 3 minutes obtained without compression. What kind of networking do you have ? 1G or 10G ? what about the clients ? 1G on both sides. What OS are the clients running ? windows, mac and linux. The test was made with a linux client. Looking at ZFS layer described at http://www.opensolaris.org/os/community/zfs/source/ , it seems that the ZIL can play this role, as it is able to store the data uncompressed on a disk before passing the data to ZIO for the compression and the transfer to the final drives. The ZIL is not a cache it is used to provide the synchronous requirements for calls such as fsync() and the requirements of NFS. Fortunately, I got two idle drives in the server that I can use as log devices for my data pool. To be useful as a log device it must be faster than the pool devices. You may see some benefit using a 15k RPM drive if your main pool devices are 7200rpm. > Unfortunately, it has no effect on write performances, so I guess I was wrong in thinking that the ZIL can cache the data before compression. However it very much depends on your workload (which you didn't describe). You may need to use a fast (and expensive) SSD or you may not have a workload that is even helped by the ZIL. So is it possible to use the ZIL cache the data before compression? Did I miss an option somewhere? The fact that the ZIL doesn't compress data is not a feature it is a very low level implementation detail. My workload is very simple: the user copy approximately 10GB of data on the server, and then only read it from time to time. During the copy on the server, the transfer is cpu bounded, and there is a lot of cpu time available when there is no copy to the server. Using a disk to store the uncompressed data, as I guess it is done by the memory cache, may have helped. I thought the ZIL may have played this role. I understand that this is very specific to a compressed filesystem, but this caching behavior would greatly enhance this kind of workload. For now, I guess I have to tune the compression rate and/or increase the amount of RAM so that ZFS can cache more data. Regards, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Wrice cache for compressed file system
Le 7 juil. 09 à 15:21, Darren J Moffat a écrit : Gaëtan Lehmann wrote: There will be two kinds of transfer protocol, once in production - CIFS and one specific to the application. But for a quick test, the test was made with scp. CIFS and scp are very different protocols with very different performance characteristics. Also really important is what the data access pattern is ? Is it read mostly or write mostly ? Are the files that are written accessed for read soon ? Is it sequential or random reads ? It is read mostly. Files are usually rarely accessed, but are likely to be accessed several times when they begin to be accessed. This is sequential read. The data set is transfered on the server, and the files are not modified after that (or very rarely). The whole data set is transfered at once. What is "good" by your definition ? The data set is transfered in a little less than 3 minutes without compression - that's good! With compression, the data set is transfered in 15 minutes. I was hopping that a disk write cache can keep the transfer speed close to the 3 minutes obtained without compression. That is a big difference and without seeing data my initial thought is that the system appears to be CPU bound, particularly if the only difference really was a compressed ZFS dataset versus an uncompressed one. Is "transfer" in this case a read from the server or a write to it ? It is a write to the server. The server is cpu bound, because of the compression. My workload is very simple: the user copy approximately 10GB of data on the server, and then only read it from time to time. During the copy on the server, the transfer is cpu bounded, and there is a lot of cpu time available when there is no copy to the server. Are you talking here about the server's CPU or the clients ? I'm talking about the server's cpu. Client is not cpu bounded by scp. >Using a disk to store the uncompressed data, as I guess it is done by the memory cache, may have helped. I thought the ZIL may have played this role. I think you are maybe confusing the ZIL and the L2ARC. I think L2ARC is for reading data - I'd like an L2ARC for writing data. What compression algorithm are you using ? The default "on" value of lzjb or are you doing something like gzip-9 ? gzip-6. There is no speed problem with lzjb, but also not the same compression ratio :-) Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Wrice cache for compressed file system
Le 7 juil. 09 à 15:54, Darren J Moffat a écrit : What compression algorithm are you using ? The default "on" value of lzjb or are you doing something like gzip-9 ? gzip-6. There is no speed problem with lzjb, but also not the same compression ratio :-) What build of OpenSolaris are you running ? The fix for "6812655 need larger kmem caches for newer workloads" might help but you need to be running build 114 or higher which means you need to be using the pkg.opensolaris.org/dev repository not the /release one. It could also be "6586537 async zio taskqs can block out userland commands" which is fixed in 115 and was the "real" fix. This is guess work though since I haven't seen perf data from your particular system. I think it's 2008.11. I won't be able to access that host until next week. I'll update the OS and post the result on the list. Thanks, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Why is Solaris 10 ZFS performance so terrible?
r2m41.81s sys 9m46.76s Feel free to clean up with 'zfs destroy rpool/zfscachetest'. I am interested to hear about systems which do not suffer from this bug. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Why is Solaris 10 ZFS performance so terrible?
Le 14 juil. 09 à 18:09, Bob Friesenhahn a écrit : On Tue, 14 Jul 2009, Jorgen Lundman wrote: I have no idea. I downloaded the script from Bob without modifications and ran it specifying only the name of our pool. Should I have changed something to run the test? If your system has quite a lot of memory, the number of files should be increased to at least match the amount of memory. We have two kinds of x4500/x4540, those with Sol 10 10/08, and 2 running svn117 for ZFS quotas. Worth trying on both? It is useful to test as much as possible in order to fully understand the situation. Since results often get posted without system details, the script is updated to dump some system info and the pool configuration. Refresh from http://www.simplesystems.org/users/bfriesen/zfs-discuss/zfs-cache-test.ksh Here is the result on another host with faster drives (sas 1 rpm) and solaris 10u7. System Configuration: Sun Microsystems SUN FIRE X4150 System architecture: i386 System release level: 5.10 Generic_139556-08 CPU ISA list: amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 Pool configuration: pool : rpool état : ONLINE purger : aucun requis configuration : NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror ONLINE 0 0 0 c1t0d0s0 ONLINE 0 0 0 c1t1d0s0 ONLINE 0 0 0 erreurs : aucune erreur de données connue zfs unmount rpool/zfscachetest zfs mount rpool/zfscachetest Doing initial (unmount/mount) 'cpio -C 131072 -o > /dev/null' 48000256 blocs real4m56.84s user0m1.72s sys 0m28.48s Doing second 'cpio -C 131072 -o > /dev/null' 48000256 blocs real13m48.19s user0m2.07s sys 0m44.45s Feel free to clean up with 'zfs destroy rpool/zfscachetest'. -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How to "mirror" an entire zfs pool to another pool
Le 28 juil. 09 à 15:54, Darren J Moffat a écrit : > How do I monitor the progress of the transfer? Once Unfortunately there is no easy way to do that just now. When the 'zfs recv' finishes is it is done. I've just found pv (pipe viewer) today (http://www.ivarch.com/programs/pv.shtml ) which is packaged in /contrib (http://pkg.opensolaris.org/contrib/p5i/0/pv.p5i ). You can do zfs send -R oldp...@sendit | pv -s 3T | zfs recv -vFd newpool and you'll see a message like that: 8GO 0:00:05 [5,71GO/s] [=> ] 7% ETA 0:00:58 A nice and simple way to get a progress report! Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] feature proposal
Le 31 juil. 09 à 10:24, dick hoogendijk a écrit : On Wed, 29 Jul 2009 17:34:53 -0700 Roman V Shaposhnik wrote: On the read-write front: wouldn't it be cool to be able to snapshot things by: $ mkdir .zfs/snapshot/ I've followed this thread but I fail to see the advantages of this. I guess I miss something here. Can you explain to me why the above would be better (nice to have) then "zfs create whate...@now?" Because it can be done on any host mounting this file system through a network protocol like NFS or CIFS. A nice feature for a NAS. Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs receive -o
Hi, One thing I miss in zfs is the ability to override an attribute value in zfs receive - something like the -o option in zfs create. This option would be particularly useful with zfs send -R to make a backup and be sure that the destination won't be mounted zfs send -R f...@snap | ssh myhost zfs receive -d -o canmount=off backup/host or to have compressed backups, because the compression attribute may be sent with the file system and thus is not necessarily inherited zfs send -R f...@snap | ssh myhost zfs receive -d -o canmount=off -o compression=gzip backup/host It is possible to use -u for the mount problem, but it is not absolutely safe until the property is actually changed. An unexpected reboot can put the backup server in maintenance mode because the file system may have the same mountpoint as another one already there. Do I miss something? Would it be possible to have such an option? Regards, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] snv_110 -> snv_121 produces checksum errors on Raid-Z pool
Le 2 sept. 09 à 15:27, Frank Middleton a écrit : On 09/02/09 05:40 AM, Henrik Johansson wrote: For those of us which have already upgraded and written data to our raidz pools, are there any risks of inconsistency, wrong checksums in the pool? Is there a bug id? This may not be a new problem insofar as it may also affect mirrors. As part of the ancient "mirrored drives should not have checksum errors thread", I used Richard Elling's amazing zcksummon script http://www.richardelling.com/Home/scripts-and-programs-1/zcksummon to help diagnose this (thanks, Richard, for all your help). The bottom line is that hardware glitches (as found on cheap PCs without ECC on buses and memory) can put ZFS into a mode where it detects bogus checksum errors. If you set copies=2, it seems to always be able to repair them, but they are never actually repaired. Every time you scrub, it finds a checksum error on the affected file(s) and it pretends to repair it (or may fail if you have copies=1 set). Note: I have not tried this on raidz, only mirrors, where it is highly reproducible. It would be really interesting to see if raidz gets results similar to the mirror case when running zcksummon. Note I have NEVER had this problem on SPARC, only on certain bargain-basement PCs (used as X-Terminals) which as it turns out have mobos notorious for not detecting bus parity errors. If this is the same problem, you can certainly mitigate it by setting copies=2 and actually copying the files (e.g., by promoting a snapshot, which I believe will do this - can someone confirm?). My guess is that snv121 has done something to make the problem more likely to occur, but the problem itself is quite old (predates snv100). Could you share with us some details of your hardware, especially how much memory and if it has ECC orbus parity? I see the same problem on a workstation with ECC RAM and disks in mirror. The host is a Dell T5500 with 2 cpus and 24 GB of RAM. Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] nuke lots of snapshots
Le 3 sept. 09 à 19:57, Jacob Ritorto a écrit : Sorry if this is a faq, but I just got a time sensitive dictim from the higherups to disable and remove all remnants of rolling snapshots on our DR filer. Is there a way for me to nuke all snapshots with a single command, or to I have to manually destroy all 600+ snapshots with zfs destroy? zfs list -r -t snapshot -o name -H pool | xargs -tl zfs destroy should destroy all the snapshots in a pool Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] snv_110 -> snv_121 produces checksum errors on Raid-Z pool
Le 3 sept. 09 à 21:59, Simon Breden a écrit : So what's the consensus on checksum errors appearing within mirror vdevs? Is it caused the same bug announced by Adam, or is something else causing it? If so, what's the bug id? Sorry, I forgot to report the end of my experiments. They shown that the checksum error I've seen are unlikely related to snv 121. The checksum errors I've seen is more likely caused by the iommu bug on intel platforms which has lead to several crash some time ago, and a lack of scrub in the last days. After the errors reported during the scrub on snv 121, I run a scrub on snv 118 and find the same amount of error, all on rpool/dump. I dropped that zvol, rerun the scrub again still on snv 118 without any error. After a reboot on snv 121 and a new scrub, no checksum error are reported. Regards, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
