And sleeping every frickin 7 seconds is so life preserving
Greetings
David
And sleeping every frickin 7 seconds is so life preserving
Greetings
David
For the price it deserve a WD-RE or an HGST UltraStar. Same power savings, better reliability.
You have to take those settings with a grain of salt. You only want to adjust that for writing performance issues, should not affect reads from the NAS. For my setup, 256 pages was working okay but it wasn't best. I reduced it to 128 pages and I was able to get constant 120MB/s writes. That's with my current setup of x3 drives on RAID5. For a friend of mine, the 256 pages cache for stripe was best, and he has RAID6 with about 12 drives. Going under or above has serious side effects on the writing performance, I don't understand how people can adjust that at such an insane high level and expect good results. There's a reason for the Debian devs to be conservative about this setting.
You can find that value in so many "md raid tuning" tutorials, i dont think that it will harm your raid in any case...
I´m pretty sure that the value is not best for all settings, but 8192 works for most. Even Volker implemented that value: http://sourceforge.net/p/openmediavault/code/848/
You have to take those settings with a grain of salt. You only want to adjust that for writing performance issues, should not affect reads from the NAS. For my setup, 256 pages was working okay but it wasn't best. I reduced it to 128 pages and I was able to get constant 120MB/s writes. That's with my current setup of x3 drives on RAID5. For a friend of mine, the 256 pages cache for stripe was best, and he has RAID6 with about 12 drives. Going under or above has serious side effects on the writing performance, I don't understand how people can adjust that at such an insane high level and expect good results. There's a reason for the Debian devs to be conservative about this setting.
Yeah already tried adjusting striping (128k or 64k gives best R/W), and it works well on SMB, but nothing on AFP. But as I said earlier, I'm happy with SMB. I keep AFP for TimeMachine only and it's better that way. I'm only waiting for AFP being executed from Apple, and then I'll throw a big party.
Well I sort of steered away from the subject, sorry about that. It is odd that you have that problem though. I do have mine with AFP and I am getting full 120MB/s speeds and I didn't have to do anything special to achieve that. My only suggestion is to turn off Service Discovery from the Network section on OMV for everything but AFP. Also make sure that the name represented in that section is the same you use in the description section for SMB. That way, OSX will know is the same server and only present you with the AFP mount options. My only theory is that you may be using a service that may not actually be AFP, even if it works. I had a hard time telling the services apart until I turned off discovery on everything but AFP.
Yeah I tried that too. I accessed the share using adress bar with afp://.
But in fact it's a software isssue on 10.9. With a VM of OSX 10.8 on my linux laptop, about 95Mbps R/W. Mystery solved.
I'll try to install hackintosh 10.9 on my laptop for further testing.
Well I just noticed a pattern on your logs:
Dec 24 17:23:06 SJOMV afpd[27537]: afp_alarm: child timed out, entering disconnected state
Dec 24 17:23:06 SJOMV afpd[27537]: dsi_disconnect: entering disconnected state
Dec 24 17:23:06 SJOMV afpd[27537]: dsi_wrtreply: Bad file descriptor
Dec 24 17:23:06 SJOMV afpd[27537]: dsi_disconnect: entering disconnected state
Dec 24 17:23:06 SJOMV afpd[27537]: dsi_disconnect: entering disconnected state
Dec 24 17:23:06 SJOMV afpd[24808]: AFP3.3 Login by Wastl
Dec 24 17:23:06 SJOMV afpd[24808]: afp_disconnect: trying primary reconnect
Dec 24 17:23:06 SJOMV afpd[15073]: Reconnect: transfering session to child[27537]
Dec 24 17:23:06 SJOMV afpd[15073]: Reconnect: killing new session child[24808] after transfer
Dec 24 17:23:06 SJOMV afpd[27537]: afp_dsi_transfer_session: succesfull primary reconnect
Dec 24 17:23:13 SJOMV afpd[24808]: afp_disconnect: primary reconnect succeeded
Dec 24 17:23:55 SJOMV afpd[19174]: afp_alarm: child timed out, entering disconnected state
Dec 24 17:23:55 SJOMV afpd[19174]: dsi_disconnect: entering disconnected state
Dec 24 17:23:55 SJOMV afpd[19174]: dsi_disconnect: entering disconnected state
Dec 24 17:23:55 SJOMV afpd[24858]: AFP3.3 Login by Wastl
Dec 24 17:23:55 SJOMV afpd[24858]: afp_disconnect: trying primary reconnect
Dec 24 17:23:55 SJOMV afpd[15073]: Reconnect: transfering session to child[19174]
Dec 24 17:23:55 SJOMV afpd[15073]: Reconnect: killing new session child[24858] after transfer
Dec 24 17:23:55 SJOMV afpd[19174]: afp_dsi_transfer_session: succesfull primary reconnect
Dec 24 17:23:57 SJOMV afpd[24858]: afp_disconnect: primary reconnect succeeded
Alles anzeigen
And this:
Dec 23 08:51:20 SJOMV afpd[9187]: AFP3.3 Login by Alois
Dec 23 08:51:20 SJOMV afpd[9187]: afp_zzz: entering normal sleep
Dec 23 08:53:22 SJOMV afpd[9187]: AFP logout by Alois
Dec 23 08:53:22 SJOMV afpd[9187]: AFP statistics: 1479.59 KB read, 55168.04 KB written
Dec 23 08:53:22 SJOMV afpd[9187]: done
Dec 23 08:57:05 SJOMV afpd[9608]: AFP3.3 Login by Wastl
Dec 23 08:59:28 SJOMV afpd[9608]: AFP logout by Wastl
Dec 23 08:59:28 SJOMV afpd[9608]: AFP statistics: 65768.39 KB read, 88139.68 KB written
Dec 23 08:59:28 SJOMV afpd[9608]: done
Dec 23 09:51:15 SJOMV afpd[13599]: AFP3.3 Login by Alois
Dec 23 09:51:22 SJOMV afpd[13599]: afp_zzz: entering normal sleep
Dec 23 09:53:17 SJOMV afpd[13599]: AFP logout by Alois
Dec 23 09:53:17 SJOMV afpd[13599]: AFP statistics: 1257.24 KB read, 55155.51 KB written
Dec 23 09:53:17 SJOMV afpd[13599]: done
Dec 23 09:57:05 SJOMV afpd[14018]: AFP3.3 Login by Wastl
Dec 23 09:58:29 SJOMV afpd[14018]: AFP logout by Wastl
Alles anzeigen
It is very odd, but it could be a Time Machine job gone wrong attempting again and again to finish or start. I've seen this kind of behavior before with Snow Leopard and even Lion. All I did was remove the old backups from the NAS and redo them from scratch. Let me know how that goes.
Guys, my post is from december 2012. It is working flawlessly since I changed the value to 8192
Yeah I tried that too. I accessed the share using adress bar with afp://.
But in fact it's a software isssue on 10.9. With a VM of OSX 10.8 on my linux laptop, about 95Mbps R/W. Mystery solved.
I'll try to install hackintosh 10.9 on my laptop for further testing.
So as I suspected, AFP <-> Netatalk is pretty shitty in 10.9
OSX 10.9 : +- 35Mbps
Hackintosh 10.9 : +- 35 Mbps
Hackintosh 10.8 : +- 95 Mbps
VM 10.8 on Debian : +- 95Mbps
Maybe a netatalk compatibility issue. Anyway I never doubted OMV
Alles anzeigen
So as I suspected, AFP <-> Netatalk is pretty shitty in 10.9
OSX 10.9 : +- 35Mbps
Hackintosh 10.9 : +- 35 Mbps
Hackintosh 10.8 : +- 95 Mbps
VM 10.8 on Debian : +- 95Mbps
Maybe a netatalk compatibility issue. Anyway I never doubted OMV
debian/OMV uses Netatalk 2.2.2 which is 2.5 years old version. If you give me your testing methology, I can perform tests on 2.2.2 and 3.1.0 for comparison.
The old netatalks have some features missing. At leaste the Netatalk version for Kralizec performs ok. But still i would prefer a actual version
BlackMagic Speed Test: up to 120MB
Finder: 2 concurrent copies checked via Activity Monitor/Network: 120MB/s ...
XBench:
Results 81.22
System Info
Xbench Version 1.3
System Version 10.9.4 (13E28)
Physical RAM 16384 MB
Model MacBookPro11,3
Disk Test 81.22
Sequential 48.41
Uncached Write 23.73 14.57 MB/sec [4K blocks]
Uncached Write 164.27 92.94 MB/sec [256K blocks]
Uncached Read 34.55 10.11 MB/sec [4K blocks]
Uncached Read 183.34 92.14 MB/sec [256K blocks]
Random 252.12
Uncached Write 129.83 13.74 MB/sec [4K blocks]
Uncached Write 289.57 92.70 MB/sec [256K blocks]
Uncached Read 370.97 2.63 MB/sec [4K blocks]
Uncached Read 496.60 92.15 MB/sec [256K blocks]
debian/OMV uses Netatalk 2.2.2 which is 2.5 years old version. If you give me your testing methology, I can perform tests on 2.2.2 and 3.1.0 for comparison.
I transfered a 45Gb video, using both ultracopier and finder.
Hmm, i transferred 4 TB today, OS X 10.9.4 via afp to omv (1.x). Transfer speed 80mb/s (the source drive wasn't faster). Mostly big files (100mb+)
Hmm, i transferred 4 TB today, OS X 10.9.4 via afp to omv (1.x). Transfer speed 80mb/s (the source drive wasn't faster). Mostly big files (100mb+)
I will try OMV 1.x then
I transfered a 45Gb video, using both ultracopier and finder.
I have cloned both vm's from fresh install of 1.0.14. One with included netatalk, other with compiled 3.1.0, just basic configuration.
Both were between 105-119MB/s with one large file, only difference was OSX recognizing 3.1.0 as time capsule.
debian/OMV uses Netatalk 2.2.2 which is 2.5 years old version. If you give me your testing methology, I can perform tests on 2.2.2 and 3.1.0 for comparison.
I was curious about netatalk 3, main difference is the shares can now be indexed by spotlight and of course a different syntax for configuration. How is the spotlight working for you?
I've build a custom version for a VM now for testing and I am thinking of moving it to my main machine. I'll have to leave the omv netatalk interface behind.
Also stock wheezy is 2.2.2. Version 2.2.5 is in the Sid repo, has the main difference that allows symlinks which I find very useful
I was curious about netatalk 3, main difference is the shares can now be indexed by spotlight and of course a different syntax for configuration. How is the spotlight working for you?
I've build a custom version for a VM now for testing and I am thinking of moving it to my main machine. I'll have to leave the omv netatalk interface behind.
Also stock wheezy is 2.2.2. Version 2.2.5 is in the Sid repo, has the main difference that allows symlinks which I find very useful
I use AFP for timemachine only so I dont use spotlight there at all.
I was curious about netatalk 3, main difference is the shares can now be indexed by spotlight and of course a different syntax for configuration. How is the spotlight working for you?
I've build a custom version for a VM now for testing and I am thinking of moving it to my main machine. I'll have to leave the omv netatalk interface behind.
Also stock wheezy is 2.2.2. Version 2.2.5 is in the Sid repo, has the main difference that allows symlinks which I find very useful
Im presently in the middle of an OMV3 build and thought it was plain sailing from here - but I can't get spotlight to index my AFP share. Is any special configuration required to get this to work? Thanks
Sorry to disappoint you but spotlight does not refer to spotlight OS X (took me a while to figure this out). Is a feature intended for gnome tracker (search engine for Linux desktop). If you want spotlight to index AFP I think you need to configure in OS X using cli so spotlight indexes the volume, this IMO it doesn't work. Maybe it works better with some net storage solutions from apple like airport.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!