bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ parted-Bugs-303360 ] Error when resizing an HFS+ partition


From: noreply
Subject: [ parted-Bugs-303360 ] Error when resizing an HFS+ partition
Date: Thu, 27 Jul 2006 05:34:05 +0000

Bugs item #303360, was opened at 13/04/2006 14:15
You can respond by visiting: 
http://alioth.debian.org/tracker/?func=detail&atid=410685&aid=303360&group_id=30287

Category: libparted
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Benjamin Cama (benoar-guest)
Assigned to: Guillaume Knispel (xilun-guest)
Summary: Error when resizing an HFS+ partition

Initial Comment:
This what i get when trying to resize the HFS+ partition on my main hard drive :

GNU Parted 1.7.0rc4
Using /dev/hda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print

Disk /dev/hda: 60.0GB
Sector size (logical/physical): 512B/512B
Partition Table: mac

Number  Start   End     Size    File system  Name     Flags
 1      0.51kB  32.8kB  32.3kB               primary
 5      32.8kB  8033kB  8001kB  hfs          primary  boot
 3      134MB   54.8GB  54.6GB  hfs+         primary
 4      54.8GB  59.4GB  4611MB  ext3         primary
 2      59.4GB  60.0GB  640MB   linux-swap   primary  swap

(parted) resize 3
Start?  [134MB]?
End?  [54.8GB]? 44GB
Error: Trying to register an extent starting at block 0x135D63, but another one 
already exists at this position.  You should
check the file system!
Error: Could not cache the file system in memory.
Error: Data relocation has failed.
Error: Resizing the HFS+ volume has failed.
(parted)


I'm trying to resize (shrink) a 55GB HFS+ partition on my G4 iBook,
kernel 2.6.14.3. The filesystem has been checked and re-checked, this is
not the problem. I know i have enough free space to shrink it by 10GB
(i've got 23GB of free space on it).

I know this may not be very useful informations, but if someone (apart
from Leslie ;-)) could help me on this, i could provide additional
information if i know what to check in the code (i saw the
--enable-hfs-extract-fs in the configure, but it produces some big
files : about 100MB, so ...)

----------------------------------------------------------------------

>Comment By: Benjamin Cama (benoar-guest)
Date: 27/07/2006 07:34

Message:
connecté 
user_id=13781

Ok, glad that it isn't a bug in parted, but this is quite sad for me and my 
efforts to try resizing this partition...

I still tried to solve this problem by looking at the names of the conflicting 
files, when the extent came from the catalog (by looking at 
catalog_key->node_name) and moved them to another partition. Strangely enough, 
it seems that (i'm not totally sure) they were all created when using (writing 
to) this partition with linux, and not OSX. So i'd like to find out if there's 
a bug in the kernel's hfs+ writing code.

Diggin a bit, i saw that allocation blocks are allocated by looking at a bitmap 
(the allocation file), and i found that the problem could originate from two 
different places :
1) OSX not correctly setting the allocated extents in the bitmap, or
2) linux not correctly looking at the bitmap to see if the extent is already 
allocated

Is there a way to detect this ? I'm not an hfs guru, so i'd be pleased to be 
advised by someone who's more skilled.

By the way, while trying to move conflicting file, i stumbled on two extents 
starting a the same address but none of them belonged to the catalog, so i 
don't know how to get the name of these files. I think that i may look at 
extent_key->parent_ID, but then i don't know where to go from here.

Sorry if this discussion doesn't belong to this bug, please email me privately 
if you think so.

----------------------------------------------------------------------

Comment By: Guillaume Knispel (xilun-guest)
Date: 27/07/2006 00:00

Message:
connecté 
user_id=11449

This entry as been closed as this is not a bug. The problem comes from 
filesystem corruption before use of parted.

----------------------------------------------------------------------

Comment By: Guillaume Knispel (xilun-guest)
Date: 26/07/2006 23:55

Message:
connecté 
user_id=11449

After analysis of the backtraces, I found that the first extent caching comes 
from the "catalog" special file and the second one from the "extents" special 
file :

* in the first bt "hfsplus_cache_from_catalog" calls "hfsc_cache_add_extent" 
with the "where" parameter set to 6, meaning CR_BTREE_CAT as you can check in 
cache.h

* in the second bt, "hfsplus_cache_from_extent" calls "hfsc_cache_add_extent" 
with the "where" parameter set to 8 meaning CR_BTREE_EXT_0.

both means normal file, respectively whose extents is described in catalog and 
extents file. The only affectations of where to those values in 
"hfsplus_cache_from_extent" and "hfsplus_cache_from_catalog" makes it clear 
this meaning is respected in the code.

So this is a FS corruption, as the TN1150 is clear about the fact this case 
should not happen :

from http://developer.apple.com/technotes/tn/tn1150.html :

"HFS Plus tracks which allocation blocks belong to a fork by maintaining a list 
of the fork's extents. An extent is a contiguous range of allocation blocks 
allocated to some fork, represented by a pair of numbers: the first allocation 
block number and the number of allocation blocks. For a user file, the first 
eight extents of each fork are stored in the volume's catalog file. Any 
additional extents are stored in the extents overflow file, which is also 
organized as a B-tree."

[...]

"For each fork, the first eight extents are described by the HFSPlusForkData 
field in the catalog file record. If a fork is sufficiently fragmented to 
require more than eight extents, the remaining extents are described by extent 
records in the extents overflow file."

[...]

"The file record in the catalog B-tree contains a record of the first eight 
extents of each fork. If there are more than eight extents in a fork, the 
remaining extents are stored in the extents overflow file."

[...]

"IMPORTANT:
Remember that the HFSPlusExtentRecord contains descriptors for eight extents. 
The first eight extents in a fork are held in its catalog file record. So the 
number of extent records for a fork is ((number of extents - 8 + 7) / 8)."

[...]

"Extents Overflow File Usage

The most important thing to remember about extents overflow file is that it is 
only used for forks with more than eight extents. In most cases, forks have 
fewer extents, and all the extents information for the fork is held in its 
catalog file record. However, for more fragmented forks, the extra extents 
information is stored in the extents overflow file."


More generally, the only extents that can appear in two differents places of 
HFS+ filesystems are thoses used for journaling. This is not the case here, and 
anyway the places this extends description appears duplicated in don't match 
the places seen here (catalog and extents special files).

Also note that physical block sharing between different files is not allowed, 
and hard link are implemented in a way so extents continue to be unique anyway.

My final conclusion is that this filesystem is corrupted.


----------------------------------------------------------------------

Comment By: Guillaume Knispel (xilun-guest)
Date: 26/07/2006 00:28

Message:
connecté 
user_id=11449

Thanks for your precise bug report.
I'll try to take care of it tomorrow.
I need to know of what type the extents are made of and i think the backtrace 
will tell me that, but i haven't had time to work on parted for a long period 
so i can't tell it right now. Need to read my code again to remember :)

Guillaume

----------------------------------------------------------------------

Comment By: Benjamin Cama (benoar-guest)
Date: 25/07/2006 08:37

Message:
connecté 
user_id=13781

I did some more investigation with gdb. Here are the function calls with 
backtrace that show the hfsc_cache_add_extent() function called twice with the 
same "start" argument :

Breakpoint 2, hfsc_cache_add_extent (cache=0x1005e3e8, start=1295235, 
length=16, block=7609, offset=7570, sbb=16 '\020',
    where=6 '\006', index=2 '\002') at cache.c:127
127             unsigned int            idx = start >> CR_SHIFT;
(gdb) bt
#0  hfsc_cache_add_extent (cache=0x1005e3e8, start=1295235, length=16, 
block=7609, offset=7570, sbb=16 '\020',
    where=6 '\006', index=2 '\002') at cache.c:127
#1  0x0ffa2908 in hfsplus_cache_from_catalog (cache=0x1005e3e8, fs=0x1005ca80, 
timer=0x1005bec0) at reloc_plus.c:568
#2  0x0ffa35ac in hfsplus_cache_extents (fs=0x1005ca80, timer=0x1005bec0) at 
reloc_plus.c:847
#3  0x0ffa3728 in hfsplus_pack_free_space_from_block (fs=0x1005ca80, 
fblock=7358238, timer=0x1005bec0, to_free=3603727)
    at reloc_plus.c:882
#4  0x0ff97ff4 in hfsplus_volume_resize (fs=0x1005ca80, geom=0x1005e708, 
timer=0x1005bec0) at hfs.c:631
#5  0x0ff99530 in hfsplus_resize (fs=0x1005ca80, geom=0x1005e708, 
timer=0x1005bec0) at hfs.c:976
#6  0x0ff580f4 in ped_file_system_resize () from 
/usr/local/lib/libparted-1.7.so.0
#7  0x100089b0 in do_resize ()
#8  0x10003ac0 in command_run ()
#9  0x1000f51c in interactive_mode ()
#10 0x1000aad0 in main ()
(gdb) c
Continuing.

Breakpoint 2, hfsc_cache_add_extent (cache=0x1005e3e8, start=1295235, 
length=16, block=53, offset=558, sbb=8 '\b',
    where=8 '\b', index=5 '\005') at cache.c:127
127             unsigned int            idx = start >> CR_SHIFT;
(gdb) bt
#0  hfsc_cache_add_extent (cache=0x1005e3e8, start=1295235, length=16, 
block=53, offset=558, sbb=8 '\b', where=8 '\b',
    index=5 '\005') at cache.c:127
#1  0x0ffa2f28 in hfsplus_cache_from_extent (cache=0x1005e3e8, fs=0x1005ca80, 
timer=0x1005bec0) at reloc_plus.c:701
#2  0x0ffa35c8 in hfsplus_cache_extents (fs=0x1005ca80, timer=0x1005bec0) at 
reloc_plus.c:847
#3  0x0ffa3728 in hfsplus_pack_free_space_from_block (fs=0x1005ca80, 
fblock=7358238, timer=0x1005bec0, to_free=3603727)
    at reloc_plus.c:882
#4  0x0ff97ff4 in hfsplus_volume_resize (fs=0x1005ca80, geom=0x1005e708, 
timer=0x1005bec0) at hfs.c:631
#5  0x0ff99530 in hfsplus_resize (fs=0x1005ca80, geom=0x1005e708, 
timer=0x1005bec0) at hfs.c:976
#6  0x0ff580f4 in ped_file_system_resize () from 
/usr/local/lib/libparted-1.7.so.0
#7  0x100089b0 in do_resize ()
#8  0x10003ac0 in command_run ()
#9  0x1000f51c in interactive_mode ()
#10 0x1000aad0 in main ()


The thing i want to know is : is this normal that two different extents have 
the same start parameter (the same allocation block address) ? Or is this an 
error in my filesystem ? I recall that this filesystem has been fsck'ed 
sucessfully.

----------------------------------------------------------------------

You can respond by visiting: 
http://alioth.debian.org/tracker/?func=detail&atid=410685&aid=303360&group_id=30287




reply via email to

[Prev in Thread] Current Thread [Next in Thread]