Re: FSGetVolumeMountInfoSize returns error -36?
Re: FSGetVolumeMountInfoSize returns error -36?
- Subject: Re: FSGetVolumeMountInfoSize returns error -36?
- From: James Bucanek <email@hidden>
- Date: Tue, 17 Aug 2010 11:04:30 -0700
Quinn "The Eskimo!" <mailto:email@hidden> wrote (Tuesday,
August 17, 2010 1:41 AM +0100):
On 17 Aug 2010, at 06:48, James Bucanek wrote:
I'm on a quest to find a way of determining whether two files are on the
same physical *device* (i.e. whether they share the same
drive, not just whether they're on the same volume--that's easy, I'm doing
that already).
Well, I'm not sure what's going on with FSGetVolumeMountInfo, and I don't have
enough time to dig into it right now, but IMO it's not on the critical path to
solving your high-level problem.
Thanks. I was really just poking around to see what I could find
out about each volume.
Rather, you should:
1. map each vRefNum to a IORegistry node
2. walk the I/O Registry to see whether the volumes are related in a way that
you care about
Step 1 is really easy: just grab the code from the VolumeToBSDNode sample.
<http://developer.apple.com/mac/library/samplecode/VolumeToBSDNode/>
Excellent!
Step 2 is a bit trickier, but most of the problems lie in deciding what you
mean by "on the same physical device", something that gets really messy once
you start considering disk images, RAIDs, cluster file systems, and so on. My
recommended approach would be to use IORegistryExplorer (in
/Developer/Applications/Utilities) to examine the cases you want to cover, and
then work a strategy from that.
I'm trying to avoid thrashing.
My product schedules extremely I/O intensive actions to run at
various times during the day/night. Not surprisingly, two or
more actions reading/writing to the same volume will slam the
disk, driving the performance of all processes into the toilet.
Two 1-hour jobs that should be done by 3AM are still running
late into the morning, and my RAID sounds like it's going to fly
off the rack...
So I don't want to run two (or more) processes when they would
all be trying to use the same drive at once. On the other hand,
I don't want to prohibit multiple actions from running
concurrently on independent devices, which the system can handle
very efficiently.
I've already added code to schedule actions to run sequentially
when those actions share the same destination volume. But that
still doesn't stop two actions from trying to use the same
drive/RAID that has been partitioned into multiple volumes.
Poking around the I/O Registry, I think my best bet is walk up
the tree and find the highest IOMedia node. There appears to be
one parent IOMedia node for each partition of volumes, whether
that's on a single hard disk or a RAID; this is exactly what I'm
looking for.
While it would be nice to also consider mounted disk images and
networked drives, those are cases that are either unlikely or
not as critical (performance wise). I'm not going to even try to
untangle clustered file systems; I think it's safe to simply
treat them as a single device and run actions one at a time.
Quinn, thanks again for sharing your encyclopedic knowledge of
the Mac's I/O system!
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden