[tmikkelsen]

We just got are new server and the Apple file service won't stay running. It looks like it's starting up, then just stops. for some reason I think this is related to my disk partitioning (why I think this I don't know). I have 3 36GB SCSI drive partitioned into about 45 partitions. Is there a limit to how many you can have from one drive? I restored the system on one of the partitions and still no luck. Any suggestions would be great.

[King Chung Huang]

While I don't know why Apple File Services won't stay up, I gotta ask: Isn't 45 partitions a bit excessive! Why do you need so many partitions?

[tmikkelsen]

Originally posted by King Chung Huang:
<STRONG>While I don't know why Apple File Services won't stay up, I gotta ask: Isn't 45 partitions a bit excessive! Why do you need so many partitions?</STRONG>

It may seem like it, but we're a digital imaging lab in a school so we need one for every TA, one for every class, one for all the staff and faculty member of the lab. A universal user disk, one for backups. It adds up. They are all only about 1.5GB.

[Grammar]

[ 07-06-2001: Message edited by: tmikkelsen ]

[King Chung Huang]

I think I understand. Are you making 45 partitions so that each TA/Class/Faculty can have their own "disk" to mount? If that is the case, then you're approaching the problem incorrectly. In that case, you would simply set up "access points" for users to access. The access points should be folders on a disk. When a user goes to the chooser to connect to the server (or however you're doing it), each access point will be displayed as a "volume" to the user.

For example, we have a commons file server which is divided up into a "Projects" volume, a "Scratch" volume, a "Mac Files" volume, and then a volume for each user (about 50 users). All of these show up as individual volumes when you connect to the server, but in reality, they exist on only a few "real" volumes. So, there's not need to create 53 partitions, in our case.

If I'm getting it all wrong and not understanding your case, let me know!

[tmikkelsen]

Originally posted by King Chung Huang:
<STRONG>I think I understand. Are you making 45 partitions so that each TA/Class/Faculty can have their own "disk" to mount? If that is the case, then you're approaching the problem incorrectly. In that case, you would simply set up "access points" for users to access. The access points should be folders on a disk. When a user goes to the chooser to connect to the server (or however you're doing it), each access point will be displayed as a "volume" to the user.

For example, we have a commons file server which is divided up into a "Projects" volume, a "Scratch" volume, a "Mac Files" volume, and then a volume for each user (about 50 users). All of these show up as individual volumes when you connect to the server, but in reality, they exist on only a few "real" volumes. So, there's not need to create 53 partitions, in our case.

If I'm getting it all wrong and not understanding your case, let me know!</STRONG>

That would almost work for us but the reason we aren't doing it that way is because we need to limit the size of the storage area. Other wise one student could take up 10GB instead of the one that their allotted. I don't think you can limit folder size on X. You can on Netware I believe. If I'm wrong save me some trouble and let me know.

[plaidpjs]

Originally posted by tmikkelsen:
<STRONG>

That would almost work for us but the reason we aren't doing it that way is because we need to limit the size of the storage area. Other wise one student could take up 10GB instead of the one that their allotted. I don't think you can limit folder size on X. You can on Netware I believe. If I'm wrong save me some trouble and let me know.</STRONG>

There is no direct control for limiting space consumption for each individual user or share point that you create. However, you can get pretty damn close through the Manager app, and you could write a pretty simple script that checks the size of the root folder for each user and sends an alert when it approaches the 1GB limit.

With that said, of course, it still doesn't explain why AFP is having start-up problems. It could conceivably be the number of partitions, but the only way I can think you could say for sure is to destroy the excess partitions and see if they same problem exists. If it does still fail to start or die, then it would have to be something in the set-up or installation.

Ciao!

[tmikkelsen]

Originally posted by plaidpjs:
<STRONG>

There is no direct control for limiting space consumption for each individual user or share point that you create. However, you can get pretty damn close through the Manager app, and you could write a pretty simple script that checks the size of the root folder for each user and sends an alert when it approaches the 1GB limit.

With that said, of course, it still doesn't explain why AFP is having start-up problems. It could conceivably be the number of partitions, but the only way I can think you could say for sure is to destroy the excess partitions and see if they same problem exists. If it does still fail to start or die, then it would have to be something in the set-up or installation.

Ciao!</STRONG>

I plan on destroying the partitions on monday when I get in. I didn't have time on friday.

That is pretty close but I still would have to manage the size myself and I wouldn't feel to comfortable deleting student files like that. I hope that it isn't the partitions or we're going to have a problem. It's hard to explain why we got a X box that won't do what are NT box did.

Thanks for your suggestions.

[plaidpjs]

Originally posted by tmikkelsen:
<STRONG>

I plan on destroying the partitions on monday when I get in. I didn't have time on friday.

That is pretty close but I still would have to manage the size myself and I wouldn't feel to comfortable deleting student files like that. I hope that it isn't the partitions or we're going to have a problem. It's hard to explain why we got a X box that won't do what are NT box did.

Thanks for your suggestions.</STRONG>

Actually, you wouldn't have to manage anything yourself once you had the script set-up. You could set it to run through cron on a regular basis, and, if it found that a calculated directory size was larger then the 1GB limit that is set, it could send out a pre-generated e-mail notice, or add a top level file, that warned the user to reduce their disk usage within 24 hours, or files would be "randomly" deleted until their folder was within the allocated range. Add a weekend skip segment to that script and you should be all set.

If only it were as easy as it sounds, right? But, it can be done.

Ciao!

[tmikkelsen]

Originally posted by plaidpjs:
<STRONG>

Actually, you wouldn't have to manage anything yourself once you had the script set-up. You could set it to run through cron on a regular basis, and, if it found that a calculated directory size was larger then the 1GB limit that is set, it could send out a pre-generated e-mail notice, or add a top level file, that warned the user to reduce their disk usage within 24 hours, or files would be "randomly" deleted until their folder was within the allocated range. Add a weekend skip segment to that script and you should be all set.

If only it were as easy as it sounds, right? But, it can be done.

Ciao!</STRONG>

I should probably mention that all the students sign in as one user for each class and there share one drive. So which student would have to delete?

Hopefuly this is all mute and that it is not the number of partitions. Although I already reinstalled and still had the problem. Well thanks for your help and ideas.

[utidjian]

That reason (amongst many others) is why I went over to Linux for a server on our networks with Apples. I have fine level access controls and control of disk quotas. Also much better performance... which was critical because some of our professors will say "OK everyone open this file..." and that file is anywhere from 10-100MB... to 16 students. Most files are about 20-40MB and the students can all get a copy open in less than minute. It took about 2+ minutes with the OS-X server.

There is a third party product called Disk Quota by Santorini, but I think it is only for OS-9 servers.

Macintosh Manager also had disk usage limits but I don't think Apple supports that any more.

In any case... seems like your best option is to run a script every so often. This could be a bit system intensive because in order to figure out how much each account is using it has to recurse the file system to the level of each user directory tree and determine their disk usage. I believe the command is "du -s filename" You could set it as a cron job to run in the small hours. It won't prevent a user from exceeding their quota but it will let you know who is. Most good quota programs will let someone save one and only one file over their quota limit and warn them... it will then NOT allow them to save any others. Your solution gives them a "hard limit" so if they have important work to save that will put them 1 byte over quota and they are SOL.

I am a tad surprised at Apple for not including such a basic administrative utility such as quotas. I am sure they will fix it someday.

[tmikkelsen]

Originally posted by utidjian:
<STRONG>...it will then NOT allow them to save any others. Your solution gives them a "hard limit" so if they have important work to save that will put them 1 byte over quota and they are SOL...</STRONG>

In are situation the server is a temp storage for when the students move between scanner, printing and work stations. They are supposed to keep everything on disk. We don't have student accounts, just one account for every class and students will delete other student work so the hard limit is not really a big deal here. I am also a little disappointed with Apple on this issue as well.