Re: Installing 9.1 without re-partitioning hard drive
On Fri, 15 Mar 2013, leeoliveshackelf...@surewest.net wrote: Good evening, Free BSD enthusiasts. Thank you to each of the several people who have responded to my previous messages. I have made significant progress, but am now flummoxed at the installation of the boot loader. The handbook says to run this command, boot0cfg -B ad0. When I run this command, I get the following error message: Unable to get providername for ad0. This message means there is no disk called ad0. On FreeBSD 9.x, it is likely to be called ada0 instead. I can't find that command in the Handbook. Could you please point out where it is? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
NFS Performance: Weirder And Weirder
This is really weird. A FreeBSD 9.1 system mounts the following: /dev/ad4s1a989M625M285M69%/ devfs 1.0k1.0k 0B 100%/dev /dev/ad4s1d7.8G 1G6.1G14%/var /dev/ad4s1e 48G9.4G 35G21%/usr /dev/ad4s1f390G127G231G35%/usr1 /dev/ad6s1d902G710G120G86%/usr1/BKU /usr1/something (under ad4s1f) and /usr1/BKU (all of ad6s1d) are exported for NFS mounting on the LAN. I have tested the speeds of these two drives locally doing a 'dd if=/dev/zero '. Their speeds are quite comparable - around 55-60 MB/s so the problem below is not an artifact of a slow drive. The two mounts are imported like this on a Linux Mint 12 machine: machine:/usr1/BKU /BKU nfs rw,soft,intr 0 0 machine:/usr1/shared /shared nfs rw,soft,intr 0 0 Problem: When I write files from the LM12 machines to /BKU the writes are 1/10 the speed of when writing to /shared. Reads are fine in both cases, at near native disk speeds being reported. Someone here suggested I get rid of any symlinks in the mount and I did that to no avail. Incidentally, the only reason I just noticed this is that I upgraded the NIC on the FreeBSD machine and the switch into which it connects to 1000Base because the LM12 machine had a built in 1000Base NIC. I also changed the cables on both machines to ensure they were not the problem. Prior to this, I was bandwidth constrained by the 100Base so I never saw NFS performance as an issue. When I upgraded, I expected faster transfers and when I didn't get them, I started this whole investigation. So ... I'm stumped: - It's not the drive or SATA ports because both drives show comparable performance. - It's not the cables because I can get great throughput on one of the NFS mountpoints. - It's neither NIC for the same reason. Does anyone: A) Have a clue what might be doing this B) Have a suggestion how to track down the problem Thanks, -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Upgrade from 6.4 to 9.1?
I have an old system happily running 6.4 but am finding that it can no longer download or build a ports index. Thus I guess it's time to upgrade. What gotchas do I need to look out for? In the past my upgrades have always been simply downloading new source, reviewing kernel config file, and then rebuilding the system. Any ports that didn't work after that I would just rebuild as well. However I've never waited this long to upgrade. Do I need to do anything different? Thanks, Drew -- Like card tricks? Visit The Alchemist's Warehouse to learn card magic secrets for free! http://alchemistswarehouse.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Upgrade from 6.4 to 9.1?
In the last episode (Mar 16), Drew Tomlinson said: I have an old system happily running 6.4 but am finding that it can no longer download or build a ports index. Thus I guess it's time to upgrade. What gotchas do I need to look out for? In the past my upgrades have always been simply downloading new source, reviewing kernel config file, and then rebuilding the system. Any ports that didn't work after that I would just rebuild as well. However I've never waited this long to upgrade. Do I need to do anything different? You won't be able to do a straight source build from 6.4 to 9.1; too many low-level changes like Makefile syntax and compiler options have changed. If you are comfortable with temporarily disabling non-essential things that fail to build, it is definitely possible to do a long jump to 9.1, but it'd be safer to either hop from 6.4 - (7-stable or 8-stable) - 9 doing buildkernels and buildworlds, or just do a binary upgrade of kernel and base system to 9.1. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
On Sat, Mar 16, 2013 at 11:49 AM, Tim Daneliuk tun...@tundraware.comwrote: This is really weird. A FreeBSD 9.1 system mounts the following: /dev/ad4s1a989M625M285M69%/ devfs 1.0k1.0k 0B 100%/dev /dev/ad4s1d7.8G 1G6.1G14%/var /dev/ad4s1e 48G9.4G 35G21%/usr /dev/ad4s1f390G127G231G35%/usr1 /dev/ad6s1d902G710G120G86%/usr1/BKU /usr1/something (under ad4s1f) and /usr1/BKU (all of ad6s1d) are exported for NFS mounting on the LAN. I have tested the speeds of these two drives locally doing a 'dd if=/dev/zero '. Their speeds are quite comparable - around 55-60 MB/s so the problem below is not an artifact of a slow drive. The two mounts are imported like this on a Linux Mint 12 machine: machine:/usr1/BKU /BKU nfs rw,soft,intr 0 0 machine:/usr1/shared /shared nfs rw,soft,intr 0 0 Problem: When I write files from the LM12 machines to /BKU the writes are 1/10 the speed of when writing to /shared. Reads are fine in both cases, at near native disk speeds being reported. Someone here suggested I get rid of any symlinks in the mount and I did that to no avail. Incidentally, the only reason I just noticed this is that I upgraded the NIC on the FreeBSD machine and the switch into which it connects to 1000Base because the LM12 machine had a built in 1000Base NIC. I also changed the cables on both machines to ensure they were not the problem. Prior to this, I was bandwidth constrained by the 100Base so I never saw NFS performance as an issue. When I upgraded, I expected faster transfers and when I didn't get them, I started this whole investigation. So ... I'm stumped: - It's not the drive or SATA ports because both drives show comparable performance. - It's not the cables because I can get great throughput on one of the NFS mountpoints. - It's neither NIC for the same reason. Does anyone: A) Have a clue what might be doing this B) Have a suggestion how to track down the problem Thanks, -- --**--** Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ With respect to your mount points : /usr1 is spanning TWO different partitions : /dev/ad4s1f390G127G231G35%/usr1 /dev/ad6s1d902G710G120G86%/usr1/BKU because /usr1/BKU is a sub-directory of /usr1 . If you create a new directory , for example /usr2 , and /usr2/BKU , and using this new separate directory for sharing , such as : /dev/ad6s1d902G710G120G86%/usr2/BKU and machine:/usr2/BKU /BKU nfs rw,soft,intr 0 0 will it make difference ? Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
On 03/16/2013 04:20 PM, Mehmet Erol Sanliturk wrote: With respect to your mount points : /usr1 is spanning TWO different partitions : /dev/ad4s1f390G127G231G35%/usr1 /dev/ad6s1d902G710G120G86%/usr1/BKU because /usr1/BKU is a sub-directory of /usr1 . If you create a new directory , for example /usr2 , and /usr2/BKU , and using this new separate directory for sharing , such as : /dev/ad6s1d902G710G120G86%/usr2/BKU and machine:/usr2/BKU /BKU nfs rw,soft,intr 0 0 will it make difference ? Mehmet Erol Sanliturk I just tried this and it made no difference. The same file copied onto the NFS mount on /usr1/shared takes about 20x as long when coppied on to /usr[1|2]/BKU. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
On Sat, Mar 16, 2013 at 3:07 PM, Tim Daneliuk tun...@tundraware.com wrote: On 03/16/2013 04:20 PM, Mehmet Erol Sanliturk wrote: With respect to your mount points : /usr1 is spanning TWO different partitions : /dev/ad4s1f390G127G231G35%/usr1 /dev/ad6s1d902G710G120G86%/usr1/BKU because /usr1/BKU is a sub-directory of /usr1 . If you create a new directory , for example /usr2 , and /usr2/BKU , and using this new separate directory for sharing , such as : /dev/ad6s1d902G710G120G86%/usr2/BKU and machine:/usr2/BKU /BKU nfs rw,soft,intr 0 0 will it make difference ? Mehmet Erol Sanliturk I just tried this and it made no difference. The same file copied onto the NFS mount on /usr1/shared takes about 20x as long when coppied on to /usr[1|2]/BKU. -- --**--** Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ Michael W. Lucas in Absolute FeeBSD , 2nd Edition , ( ISBN : 978-1-59327-151-0 ) , is suggesting the following ( p. 248 ) : In client ( mount , or , fstab ) , use options ( -o tcp , intr , soft , -w=32768 , -r=32768 ) tcp option will request a TCP mount instead of UDP mount , because FreeBSD NFS defaults to running over UDF . This subject may be another check point . Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
just slap an netapp 8.x with an avere flash box in front if you want NFS performance... or isilon. On Sat, Mar 16, 2013 at 5:43 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Sat, Mar 16, 2013 at 3:07 PM, Tim Daneliuk tun...@tundraware.com wrote: On 03/16/2013 04:20 PM, Mehmet Erol Sanliturk wrote: With respect to your mount points : /usr1 is spanning TWO different partitions : /dev/ad4s1f390G127G231G35%/usr1 /dev/ad6s1d902G710G120G86%/usr1/BKU because /usr1/BKU is a sub-directory of /usr1 . If you create a new directory , for example /usr2 , and /usr2/BKU , and using this new separate directory for sharing , such as : /dev/ad6s1d902G710G120G86%/usr2/BKU and machine:/usr2/BKU /BKU nfs rw,soft,intr 0 0 will it make difference ? Mehmet Erol Sanliturk I just tried this and it made no difference. The same file copied onto the NFS mount on /usr1/shared takes about 20x as long when coppied on to /usr[1|2]/BKU. -- --**--** Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ Michael W. Lucas in Absolute FeeBSD , 2nd Edition , ( ISBN : 978-1-59327-151-0 ) , is suggesting the following ( p. 248 ) : In client ( mount , or , fstab ) , use options ( -o tcp , intr , soft , -w=32768 , -r=32768 ) tcp option will request a TCP mount instead of UDP mount , because FreeBSD NFS defaults to running over UDF . This subject may be another check point . Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Upgrade from 6.4 to 9.1?
Dan Nelson wrote: In the last episode (Mar 16), Drew Tomlinson said: I have an old system happily running 6.4 but am finding that it can no longer download or build a ports index. Thus I guess it's time to upgrade. What gotchas do I need to look out for? In the past my upgrades have always been simply downloading new source, reviewing kernel config file, and then rebuilding the system. Any ports that didn't work after that I would just rebuild as well. However I've never waited this long to upgrade. Do I need to do anything different? You won't be able to do a straight source build from 6.4 to 9.1; too many low-level changes like Makefile syntax and compiler options have changed. If you are comfortable with temporarily disabling non-essential things that fail to build, it is definitely possible to do a long jump to 9.1, but it'd be safer to either hop from 6.4 - (7-stable or 8-stable) - 9 doing buildkernels and buildworlds, or just do a binary upgrade of kernel and base system to 9.1. The best approach is to backup your user data and do a fresh install from 9.1 cdrom. You will bypass a bunch of headaches which may in the end force you to do a fresh install anyway. And it will save you a lot of compile time. It's alway a good feeling to know you have a pristine system when you start having problems. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
On 03/16/2013 05:43 PM, Mehmet Erol Sanliturk wrote: Michael W. Lucas in Absolute FeeBSD , 2nd Edition , ( ISBN : 978-1-59327-151-0 ) , is suggesting the following ( p. 248 ) : In client ( mount , or , fstab ) , use options ( -o tcp , intr , soft , -w=32768 , -r=32768 ) tcp option will request a TCP mount instead of UDP mount , because FreeBSD NFS defaults to running over UDF . This subject may be another check point . Another very good suggestion but ... to no avail. Thanks for pointing this out. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
On Sat, Mar 16, 2013 at 6:46 PM, Tim Daneliuk tun...@tundraware.com wrote: On 03/16/2013 05:43 PM, Mehmet Erol Sanliturk wrote: Michael W. Lucas in Absolute FeeBSD , 2nd Edition , ( ISBN : 978-1-59327-151-0 ) , is suggesting the following ( p. 248 ) : In client ( mount , or , fstab ) , use options ( -o tcp , intr , soft , -w=32768 , -r=32768 ) tcp option will request a TCP mount instead of UDP mount , because FreeBSD NFS defaults to running over UDF . This subject may be another check point . Another very good suggestion but ... to no avail. Thanks for pointing this out. -- --**--** Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ I have read messages once more . There is a phrase : Linux Mint 12 machineS ( plural ) . In your descriptions , there is no any information about network setup : Single client , multiple clients , etc . Then , with some assumptions : If there is ONLY ONE client , and all of the tests are performed on this ONLY client , problem may be attributed to FreeBSD server or kind of file(s) in different directories : One of the is encrypted ( requires decryption ) , another is plain file , etc. . If there is MORE than ONE client , problem may be attributed to any one the components of the network ( server , clients , switch , cable , NICs , interfering other software , etc. ) . Assume there is MULTIPLE clients : Take two clients of them : (A) Client 1 : Mount two directories . (B) Client 2 : Mount two directories . Test transmission performance : If they are similar , inspect server settings , directory privileges , etc . , file systems ( one is ZFS , other is UFS2 , etc. ) . All of the hardware may work properly , but if the file reading is not able to feed NIC sufficiently fast , it may show up as degraded performance . Increasing NIC buffer size ( as standard it is around 1000 bytes ) to maximum available , may offset latency of supply of data to NIC . If they are different : Check client specialties : A cable may be CAT5 ( only maximum 100 Mbits transfer . Network cards are adaptive , they try 1 Gbits , if it is not achievable , it reduces to speed to 100 Mbits , even to 10 Mbits ) . In that case either use CAT6 cable or CAT5x ( for 1 Gbit transmission , I do not remember x now ) The cable kind should be written on cable , if it is not written , select a properly labelled cable . Interchange cable tips to clients : If performance interchanges also : Cable or SWITCH port is faulty : Check switch port : It may be a 100 Mbits , be sure that it is also 1 Gbits and working properly . Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
On 03/16/2013 10:15 PM, Mehmet Erol Sanliturk wrote: On Sat, Mar 16, 2013 at 6:46 PM, Tim Daneliuk tun...@tundraware.com mailto:tun...@tundraware.com wrote: On 03/16/2013 05:43 PM, Mehmet Erol Sanliturk wrote: Michael W. Lucas in Absolute FeeBSD , 2nd Edition , ( ISBN : 978-1-59327-151-0 ) , is suggesting the following ( p. 248 ) : In client ( mount , or , fstab ) , use options ( -o tcp , intr , soft , -w=32768 , -r=32768 ) tcp option will request a TCP mount instead of UDP mount , because FreeBSD NFS defaults to running over UDF . This subject may be another check point . Another very good suggestion but ... to no avail. Thanks for pointing this out. -- --__--__ Tim Daneliuk tun...@tundraware.com mailto:tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ I have read messages once more . There is a phrase : Linux Mint 12 machineS ( plural ) . In your descriptions , there is no any information about network setup : Single client , multiple clients , etc . Then , with some assumptions : If there is ONLY ONE client , and all of the tests are performed on this ONLY client , problem may be attributed to FreeBSD server or kind of file(s) in different directories : One of the is encrypted ( requires decryption ) , another is plain file , etc. . There is one server - FreeBSD, and one client - LM12. Both have had their cables replaced with new CAT6 wiring. Copying the exact same file to each of the NFS mounts exhibits the problem. Reading from the two NFS mount is fast and as expected, so I do not suspect network issues. The two drives used on the server show similar disk performance locally. The server side exports are identical for both mounts as are the client side mounts. The ONLY difference is that the fast NFS mount has server side permissions of 777 whereas the slow NFS mount has server side permissions of 775. Both are owned by root:wheel. The contents of each filesystem are owned by a user in the wheel group. The one other difference is that all the contents of the slow mount are in a particular user group, and all the ones in the fast mount are in the wheel group. Changing the group ownership of all the stuff in the slow mount to wheel makes no difference. The problem appears to be size related on the slow mount. When I copy, say, a 100MB file to it, performance is just fine. When I copy a 1G file, it's 1/20 the throughput (45MB/sec vs 2MB/sec). This feels like some kind of buffer starvation but the fact that I can run at full speed against another mount point leaves me scratching my head as to just where. It's almost like there's some kind of halting going on during the transfer. Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NFS Performance: Weirder And Weirder
There is one more point to check : From your mount information , in the server , directories are on DIFFERENT drives . Assume one of the drives is very INTELLIGENT to save power . During local reading , due to reading speed , it may not go to SLEEP , but during network access , it may go to sleep due to its exceeded waiting time . If this is the case , please stay away from INTELLIGENT drives in a server : These are designed and produced by very IGNORANT entities . For simple , personal applications , their latency may not be noticed very much , but in a server , they can not be used . Another point may be file sizes . To check effect of file size , into the two different directories copy a large ( for example , 5 GB , or a 4.n GB .iso file ) and transmit these same files from their directories to a single client . If directory structure makes a difference , assuming hardware parts and client does not behave differently to these files , performance difference may be attributed to server side . Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
