Large Drives and USB Enclosures

OK, this is definitely a talk to the rubber ducky kind of post.

I have an old Mandrake box that various clients send their backups to overnight. I hook up an external USB drive and run a script that basically rsyncs the various backups to the external drive to be taken off-site. Been doing it this way for a while now.

I've upgraded the size of the drive in the external enclosure a couple of times, 160G to 320G to 1TB recently. When I first got the 1TB enclosure, I partitioned it with an iMac, then remembered I couldn't format ext3 with the Mac, so I connected it to a linux box and formatted it, but left the partitioning alone. Turns out the iMac partitioned it GPT. I only realized this after I'd been using it for a couple of days. This is in the logs.
kernel: /dev/scsi/host39/bus0/target0/lun0:<4> Warning: Disk has a valid GPT signature but invalid PMBR.
kernel: Assuming this disk is *not* a GPT disk anymore.

It was working, I didn't have a handy spot to move the large amount of data on the disk to, and fixing it seemed like it would probably destroy data, so I left it for a bit. I tested restoring data from the drive to be sure, and everything was working fine.

A couple of weeks later, during a really busy spell, I noticed the daily rsync jobs turned deadly slow. Instead of 6MB/s I'm getting 300k or less. Almost like it was swapping to USB1.1 instead of 2.

I twiddled with it for a bit, and since it was somewhat intermittent I tried replacing the USB controller (it's an add on card) in the server. Over the next couple of days I tried another USB enclosure, another USB cable, and copying files from different server. The problem kind of came and went, so no one change seemed to be the fix.

Since this is the off-site backup, I had started using another (smaller) drive to copy the recent information to - this setup was working fine. I bought another 1TB drive and enclosure, both different brands than the existing units, partitioned and formatted it correctly from a linux box, and started using it. It was running fine at full speed. When I had time I started copying the older archive info that was only on the first TB drive over as well.

Now this morning that new drive started running slow....

The only thing that makes any sense at all to be at this point is some problem with USB enclosures and large drives - e.g. once it gets past 650meg or so they start having problems? But the two enclosures are completely different chipsets - one has IDE + SATA, the other is SATA only. It can't be that widespread an issue can it?

OK, so now I've typed all this out, the ducky still hasn't said anything...

Anybody else want to comment?

Finding OSX Aliases in a SMB/CIFS Share

Just a quick follow up to my previous post.

In case it wasn't obvious - if you want to find all those OSX alias files it's just a simple

grep -r XSym /path/to/smbshare/on/server


Updated:

If I had more of them I'd hack up a script to pull the path info out of them and create the symlinks automatically....


This is really hacky, but you can make symlinks out of alias files with it.
If a dragon appears and demands a dumptruck for a four-wheeler, don't blame it on me!


read NAME && LINK=$(tail -n 2 $NAME | head -n 1) && rm -v $NAME && ln -sv "$LINK" "$NAME"


Samba Unix Extensions and Following Symlinks with OSX Leopard and Ubuntu Hardy

Sorry for that title - just trying to help the Google bot help the future.

So here's the problem. When we upgraded the bulk of the Macs at work to Leopard, symlinks on the Samba share quit working. They still worked in Windows, and on Hardy clients, but not Leopard.

If you created an 'alias' in Leopard, then the Macs could follow it, but the Linux boxes not.

Lots of people have the same or similar issues -
A B C D E F

Turns out Leopard is the first OSX client to support Unix extensions in CIFS.
So the client ends up trying to follow symlinks *locally* rather than on the server. 'Dumber' clients like Windows or Gnome Nautilus smb:// don't do Unix extensions, so the server resolves the symlinks for you.

The 'fix' is to set 'unix extensions = no' globally in the smb.conf file.
Now the OSX clients won't get the unix info either, and the server will go back to resolving symlinks for them.

The drawback to this fix as I understand it is that SMB with unix extensions on is a complete replacement for NFS in that the full range of unix permissions can be provided to unix clients - it's not limited anymore. You would need some external system to keep UID/GIDs syncronized, but NFS has that issue too.

What I still don't understand is how to get symlinks to resolve to the correct spot on the server when unix extensions *is* on. E.G. if I was using a 'smart' linux client (like mount.cifs and the /etc/fstab file?) how do I get symlinks to work? Comments appreciated, as I've spent too much time on this issue at the moment anyway.

Brian

PS - I also found out that when you create an 'alias' in OSX on a SMB share, the file it creates is actually in Minchell and French format - see this page that talks about creating symlinks on Windows servers. That's what OSX does on a linux server as well. Weird the linux client doesn't follow it!