CIFS/SMB Sharing & ZFS: Best Practices for Multi-User Setups

[digitaltrash]

Dear admins, networking experts, zfs geeks, beastie devils

What are the best practices when it comes to creating windows shares for multiple users? In particular, here is what I am concerned with the most:

Supposing there are 100 users in total, with say 30 - 60 simultaneous users connected to FreeNAS via samba. Users are running XPsp3 and WIN7 boxes.

When it comes to setting up FreeNAS using ZFS Raidz2, would it be better to:

A) Setup one massive ZFS pool, make private user folders for all 100 users, create samba share for each user
B) Setup one massive ZFS pool, make ZFS datasets for each user, create ONE samba share for the pool, assign access permissions
C) Other ways?

I'm of the opinion that B is the right way of doing it, as I've read somewhere in sun's documentation that ZFS transfer speeds are as good as a single HDD (even for multi-HDD setups) when only one vdev is made, no matter how many disks it actually contains. More vdevs would provide more speed, until the HDD cap is reached, for multi-user setups. It also looks a bit silly to have that many samba shares, but I'm certainly no expert on this and would like to ask what you good people can suggest!

 

[louisk]

How many spindles are you planning on using?

What advantages are you expecting from using per-user datasets?

 

[digitaltrash]

9 - 12 3TB disks initially, expandable to 24 in the future. I may go with 2 sets of 6 drives configured as raidz2, giving me a 24TB pool and loosing 4 drives for redundancy. Adding the remaining 12 drives in future will force me to use the same config (not really forcing, but its desirable if added to the same pool), giving me a grand total of 48TB at a loss of 8 drives. Not bad! If I decide to go with FreeBSD, I have the option of doing raidz3, which initially ends up diving 27TB with a loss of 3 drives (for the 12 initial drives), and a grand total (for 24 drives) of 54TB at a loss of 6 drives.

From what I understand so far, raidz2 option with 4 vdevs of 6 disks will give me better I/O and throughput than a raidz3 option of 2 vdevs of 12 disks (Correct me if I'm wrong). This is coming from the desirable hierarchical setup concept from on oracle's zfs website (See the last paragraph here)

One advantage I see with dataset/user setup is that I can control space reservation and quotas directly. The backup utility with WIN7 (in our environment) is adequate, but it provides no manual control on deleting older backups (it does in server family, but not on client machines). I believe it is setup to use up to 30% of the disk before the oldest backup set deletion algorithm kicks in, with no manual control (unless you do a full disk image backup, which I won't) (common M$, this is silly of you). I could probably solve it by scripting on the client side or defining cron jobs on the server side, but that just unnecessarily complicates the setup.

 

[louisk]

Optimum performance will be when the number of data disks in a vdev is a power of 2, so 4, or 8 + 2 for parity, giving you a vdev spindle count of 6 or 10 for RAIDZ2, vs 5 or 9 for RAIDZ.

Yes, the greater the number of vdevs in your pool, the higher the IO performance will be.

I don't disagree with the principal of having quotas defined per user, but I'm not sure having quotas assigned for the backup location is good. This would mean that backups would fail if the user has met their quota, which seems like a harsh punishment, since it will likely happen to users who don't have a clue what the problem is. I would probably design it such that backups have their own location and quota is based on the capacity of the users disk * some number of backups you want to keep.

 

[digitaltrash]

Capacity of user's disk is intriguing idea at first, but 1) for 100 users of 500GB disk each, that's already 50TB, which, in my opinion is a waste of space (if the whole image is stored) since of the 500GB, only about 30GB is real user data, with the other 10-20 being the OS.. That's not considering that the number of users increases, as does the capacity of user HDD with years. And 2) WIN7 backup utility is "aware" of the space limit issue (from what Ive read, haven't checked myself yet). So, as the quota (or a percentage of the quota really) is reached, it deletes the oldest backup set on the fly, freeing up space for the new set. I'll confirm as I test this.

 

[digitaltrash]

As far as SAMBA is concerned, has anyone noticed that sometimes it is fairly sluggish during user connect/authentication? I wonder what is causing it.

In windows environment, using

Code:

net use x: \\freenas\sharefolder /user:someone password

in CMD to map the drive works really well, connecting the user in less than a second each time. If, however, one adds the "/persistent:yes" flag to remember the drive, upon consequent login using the GUI it takes about 10-20 seconds (maybe more) for apparently no reason. Sometime this behavior is propagated once it is already logged in, when accessing any folder for example, it takes some time. Any ideas why?

 

[peterh]

when using large drives resilver time must be taken serous. Using 4 drives in raidz1 will take many hours to resilver, the more
drives you have in a group the longer time it will take.
So to be able to cope with drive failures use small vdevs. This will also enhace performance.

raidz1 or raidz2 is a matter of reaction time. If you replace drive fast raidz1 will do. Remember that raid is no replacement for
real offsite backups.