Submitted by Anonymous (not verified) on Fri, 09/27/2013 - 8:14pm
When defragmenting a file with snfsdefrag on systems running OS X Mountain Lion v10.8.4 and earlier, an invisible "__defragtmp" file may be created which cannot be deleted.
This issue may occur when the following are true:
The defragmented file's name contains precomposed Unicode characters, such as letters with diacritical marks (an accent, grave, or umlaut).
snfsdefrag is run by root.
snfsdefrag is run when the current working directory is on an Xsan volume, or snfsdefrag's recursive option (-r) is used.
We currently moved from
Mac OSX 10.6.x MDCs using XSAN 2.2.x / Mac OSX Open Directory / XSAN 2.2.x Mac OS X 10.6.x Clients / Promise Storage ( all connected via Fiber Switch )
StorNext MDCs ( M440 Appliance ) version 4.7/ New Storage / Old Promise Storage was left intact and still being utilized / New MAC OS X 10.8.x XSAN Clients / Two new Windows 2008 Servers utilizing Stornext Clients All still connected via Fiber Switch.
All The Fiber connected Clients Mac OS X 10.8.x ( XSAN Client ) via Fiber & Two Windows 2008 R2 Server ( Stornext Client ) can see the old ( XSAN ) LUNs & the new ( StorNext ) LUNs and mount the volumes ( lets call this xsan1 and snfs1 ) I can see and access ALL the folders via the MAC OS X 10.8.x fiber clients but via Windows I see the volume but am not able to access "all" the contents. At first I saw the generic permission message indicating " You don't currently have permission to access this folder. Click continue to permanently get access to this folder"
At which point I can choose to continue, and take ownership of the folder. that works to a certain extent but I still get access denied while taking ownership of multiple folders and so on ..... I have been reading up on this issue and came across few things but figured I would come to the PROs and see what is the best way to approach this issue.
I also would like to utilize my Active Directory Domain to authenticate users to login to the MACs and also permission to the old Xsan volume and new snfs volume.
any help is greatly appreciated and I look forward to hearing from the PROs
This is a fresh XSAN, I started with a clean install on a wiped 10.8.5 ML Server (Xserve 2009). Have LUNs, volume, and already migrated some data to it. So far so good.
I tried for 2 hours to add (10.8.5 and 10.8.4) clients with no success. I enable XSAN in SysPrefs, XSAN Admin sees the clients easily, I authenticate, but after a while I get the message:
"Failed to write configuration files on computer"
The first 'client' was another server which I was going to promote to a secondary MDC, but never got this far. The other client was a normal Mac Pro.
I checked pings, DNS (dig), changeip -checkhostname, everything resolves just fine. OD is in place, separate private metadata network set manually with a separate subnet.
Are there any log files that'll show in more detail what's failing and where?
One thing I just thought about is that our entire facility DNS is set with A records for machines ("Solo") and CNAME for roles ("edit1"). The Add Computers window shows the CNAMEs for the machines, which looks just the way I expect it to, but is there something against having CNAMEs in an XSAN environment?
(Warning: big post follows. My apologies if this should've been posted in the General forum, it doesn't get any traffic!)
I'm planning/considering migrating from MetaSAN to XSAN. The reason as to why can be the subject of a separate discussion, let's just say that I've had some negative experience with MetaSAN and our existing infrastructure is perfect for XSAN.
Uninstalling metaSAN should be pretty darn easy, but "Apple's way" and doing things by the book assumes you prepare the infrastructure, then the clients, then the secondary MDC, and finally the primary MDC with the XSAN wizard and volume configuration. I'll then have a fully-configured yet blank SAN, so people won't be able to work for another 1-2 days until data migration is done.
I have a server (Xserve 2009) and 2 RAID arrays that are currently dark and will run the XSAN. I therefore plan to:
[i]Then/i I'll shut down everyone and turn over the environment (uninstall MetaSAN, put the XSAN on the fabric, update switch zoning, setup XSAN on clients, setup standby MDC, AFP resharing, etc.) This should be doable in one evening to the degree that users can come the next morning and work./*
Mount my MetaSAN array locally on ONE machine and synchronize changes since the backup./*/list
1. What says you? Any caveats I'm missing?
2. The most precarious step in my above plan is the last, since data hasn't been backed up between steps 1 and 6. A MetaSAN volume without MetaSAN is just plain HFS+, but can anything happen if I mount it alongside XSAN? For safety I wouldn't even trust zoning, I'd direct-attach it to a dual-port HBA (no quad-port cards in house, unfortunately).
3. XSAN installs always have pairs of data LUNs. Is this an actual requirement of XSAN, or a function of active/active RAID architecture? Why do more LUNs give better performance? My main data pool (16x2TB) will have to live on a single-controller chassis, so I was planning one big RAID6 LUN. I'd rather have one RAID6 array where any 2 drives can fail instead of 1 drive per RAID.
4. My metadata will live on an older but dual-controler RAID. If I have 4 x 500GB drives available for metadata, what RAID configuration would you recommend for them? RAID10 with metadata & journal on the same volume (and controller affinity=1)? Two separate RAID1's for metadata and journaling?
5. If the secondary MDC is the OD master, what is the power-up sequence?
6. In case I need to roll back, does binding XSAN to an OD server ("Use an existing Open Directory server") "do something" to the directory or modify records in any way?
7. When configuring the MDC, would you point to the OD master by its IP or DNS address?