1

I have a SAMBA server on my home LAN running fine. My main computer is a MacBook Pro laptop; its 320GB hard drive used to be enough for me, but now I'm filling it up, I've considering expanding it.

An alternative would be to expand my server with some more hard drives and use soft-RAID1 (I have 4 drives in two sets of mirrors at the moment) for data protection, then use either SAMBA or iSCSI to map them on my Mac, keeping data I don't need perpetual access to on this volume. Since I could have RAID protection of the volume, this is quite tempting.

SAMBA on my server manages about 22MB/sec read and write over Gb ethernet, but I'm noticing some lag with the volumes, and I'm worried I would overload the server by using it as a working disk (the server is not very powerful, being Celeron-based, built more for low power usage than processing power).

We've experimented with iSCSI at work, and I've noticed some good data rates. As the disk is a block device, it doesn't have the SAMBA level in between, so I assume it would have higher performance. I found a freeware iSCSI iniator for my Mac, and am now debating which route to go down.

I'm familiar with SAMBA and use it heavily. I've set up a tgt-based server at work which worked amazingly well first-time with Windows, and got decent transfer speeds, but we were using a potent PowerEdge machine.

I guess it boils down to, which route would be the least processor-intense for the server whilst getting good data rates. I'd be the only user of the volume, but SAMBA will be running on the server anyway. Any ideas?

Improve this question

2 Answers 2

Reset to default
3

Right. You seem to be slightly confused here, perhaps.

Samba (CIFS) and iSCSI are two very different protocols. Samba presents a file-level storage target, and iSCSI presents block storage, y'know, a disk that you then put a filesystem on.

With regard to overhead, CIFS is probably somewhat higher, given there's a layer of locking and other file-level services going on to make sure that the files stay in a reasonable sane state.

I know many iSCSI SANs heavily utilise TCP offload on the network card, so you might find that those are even less CPU intensive on the server.

I suggest that you run some benchmark tests, possibly with bonnie++ or even just your usual usage to see how you get the best performance both server and client side.

Improve this answer
6
  • Thanks for the comment, I understand the differences. I was just curious about how much overhead SAMBA's file system would use versus wrapping and unwrapping SCSI commands in IP on the server. I'll try and do some benchmarks.
    – Gargravarr
    Jul 13, 2011 at 9:47
  • I think the best results you'll get are if you do the benchmarking yourself on your own hardware.
    – Tom O'Connor
    Jul 13, 2011 at 9:52
  • Also, if you get any decent results, can you report back here, or perhaps blog it?
    – Tom O'Connor
    Jul 13, 2011 at 9:52
  • Sure thing, I'll post some results when I get around to upgrading the server.
    – Gargravarr
    Jul 13, 2011 at 11:32
  • As far as TCP checksum offloads, watch out with these settings, some software works faster with them off then on. You don't want go off assumptions, so test for your particular hardware/setup/workload.
    – Marcin
    Jul 13, 2011 at 12:38
0

If you have experience with Samba, you may have it easier to use it also in this case. If you are thinking about something other you may give NFS a try and use automount (http://i1.dk/misc/automount_nfs_volumes_on_mac_osx/) to have filesystem mounted on-demand.

I also second Tom's idea of benchmarking performance of possible solutions and see how they behave.

Improve this answer
1
  • NFS sucks on windows.
    – Tom O'Connor
    Jul 13, 2011 at 12:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .