Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
- Subject: Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
- From: Michael Alfred Schmidt <email@hidden>
- Date: Fri, 23 Jan 2009 16:28:40 +0100
Thanks, I understand. Anyway, my goal
is to shrink the volume rather than to expand it. So the repartitioning
problem shouldn't apply.
As I eventually managed to set up the
kernel debugger, I was able to verify the calling parameters of 'hfs_truncatefs()'
(in the kernel - hfs_vfsops.c).
What I figured there is that the 'newsize'
paramter always had a constant value, regardless of the various valid input
parameters that I passed into userland 'fsctl()'
for 'uiNewSize'
(see my code). So I assume that this value gets lost somewhwere between
userland and kernel. This is why I assume that I might have some kind of
thunking problem (maybe between 32-bit/64-bit code) with my input pointer.
Unfortunately, my kernel debugging skills aren't good enough yet to trace
the parameter passing to the kernel.
Thanks anyway so far!
Michael
| Shantonu Sen <email@hidden>
23.01.2009 15:52
|
|
To
| Michael Alfred Schmidt <email@hidden>
|
|
cc
| email@hidden
|
|
Subject
| Re: problems with hfs_truncatefs() /
HFS_RESIZE_VOLUME |
|
Please read my post again.
diskutil is an integrated solution that does both repartitioning
and filesystem resizing. The "limits" it prints out assume that
it is also going to be doing repartitioning.
The 128MB freespace is outside of the partition boundaries.
If you want to use it (which I don't recommend), you need to repartition
first to increase the size of your partition to use some of that freespace,
and then increase the filesystem to match.
Shantonu
Sent from my MacBook
On Jan 23, 2009, at 12:25 AM, Michael Alfred Schmidt wrote:
Shantonu,
I'm testing on a MacBook Pro with default factory partitioning, i.e. there
are 128 MB left free on top of the OS partition (see
http://developer.apple.com/technotes/tn2006/tn2166.html#SECPARTITIONINGPOLICY).
I verify upfront with 'diskutil resizeVolume <resp.
volume device> limits' what
freedom to expand or shrink I have. Since my goal is to shrink the partition
rather than to expand it anyway, I concentrate my tests on shrinking (by
~ 10%).
Michael
How do you know it has space to expand? You know you have to repartition
the disk first, right (so that the container block device is large enough).
This fsctl is something that is straightforward to use the same way the
Disk Utility/diskutil use it. How big is your filesystem? How many allocation
blocks? What sizes are you requesting?
Shantonu Sen
email@hidden
Sent from my Mac Pro
On Jan 22, 2009, at 9:06 AM, Michael Alfred Schmidt wrote:
I do get ENOSPC
in case the code runs into 'hfs_extendfs(): not
enough space on device', or
EINVAL
in case the code runs into 'hfs_truncatefs(): invalid
size'. I get both erros with
my test program when I only try often enough, i. e. I get both errors for
the same value. The same behavior (both errors possible) applies to any
other arbitrary value of uiNewSize.
This is why I believe that the value is currently somehow lost.
The volume has both sufficient site to expand and to shrink.
Michael
you certainly get a ENOSPC message somewhere, bad sample you are using
- yoda
Cheers!
On Thu, Jan 22, 2009 at 8:16 AM, Michael Alfred Schmidt
<email@hidden>
wrote:
>
> Hi,
>
> I'm trying to shrink an HFS+ partition, just as 'diskutil resizeVolume...'
> does. However, I'm facing problems implementing the HFS_RESIZE_VOLUME
> command via fsctl(), as proposed by Amit Singh on p. 1572 of 'Mac
OS X
> Internals'.
>
> My code looks as follows:
>
> int iRet = 0;
>
> u_int32_t uiBlockSize;
> u_int64_t uiBlockCount, uiCurrentSize, uiNewSize;
>
> struct statfs StatFS;
>
> // only works if device mounted
> iRet = statfs ("/etc/", &StatFS);
> if (iRet < 0)
> {
> perror ("statfs failed with");
>
> return;
> }
>
> uiBlockSize = StatFS.f_bsize;
> uiBlockCount = StatFS.f_blocks;
>
>
> printf ("block size:\t %u\n", uiBlockSize);
> printf ("block count:\t %llu\n", uiBlockCount);
>
>
> uiCurrentSize = uiBlockSize * uiBlockCount;
> printf ("partition size:\t %llu\n\n", uiBlockSize * uiBlockCount);
>
> uiNewSize = uiCurrentSize; // only test here!!!
> printf ("new volume size: %llu, hex: %llX\n", uiNewSize,
uiNewSize);
>
>
> iRet = fsctl ("/", HFS_RESIZE_VOLUME, &uiNewSize, 0);
> if (iRet < 0)
> {
> perror ("fsctl failed with");
>
> return;
> }
>
>
> fsctl() fails with either 'hfs_extendfs(): not enough space on device'
or
> 'hfs_truncatefs(): invalid size', even if the new size equals the
old size
> (as in the code sample above). It looks like the &uiNewSize input
parameter
> is fully ignored, as other "new sizes" show the same unpredictable
results.
> On the kernel side, the respective code resides in bsd/hfs/hfs_readwrite.c.
> >From looking at that code, I cannot see any obvious mistake in
my code. I'm
> wondering whether there is any thunking (pointer conversion) problem
with
> the pointer to u_int64_t in the transition from userland to kernel.
>
> My target system is Mac OS X 10.5.x (Intel), compiled with XCode 3.1
with
> default build settings.
>
>
> I'm grateful for any idea on what's wrong with my code!
> Thanks in advance!
>
> Michael
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
--
-mmw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden