>Hi Roman,
>
>I am using hfsplus (journalled) to mount a 10Gb partition on an usb
>attached disk. I then copy a 3.5Gb file to the partition, then umount,
>and mount again, and then delete it, but the space occupied by the file
>is not freed, and doing that two times in a row ends up filling up the
>space and I get an error that there is no space left. Here are steps
to
>reproduce:
I have had a similar experience with my (Mac) IPOD.
I am using kernel-2.6.12 from Fedora Core 4 on x86, but it is
just possible that this bug is still around in the latest
development kernels.
fsck_hfs reveals lots of temporary files accumulating in
the hidden directory "\000\000\000HFS+ Private Data".
According to the HFS+ documentation these are files which
are unlinked while in use. However, there may be a bug in
the Linux hfsplus implementation which causes this to happen
even when the files are not in use. It looks like the
"opencnt" field is never initialized as (I think) it should
be in hfsplus_read_inode. This means that a file can appear
to be still in use when in fact it has been closed. This patch
seems to fix it for me:
diff -U3 -r linux-2.6.12-old/fs/hfsplus/super.c
linux-2.6.12/fs/hfsplus/super.c
--- linux-2.6.12-old/fs/hfsplus/super.c 2005-06-17 20:48:29.000000000
+0100
+++ linux-2.6.12/fs/hfsplus/super.c 2005-10-23 21:15:24.000000000
+0100
@@ -50,6 +50,7 @@
init_MUTEX(&HFSPLUS_I(inode).extents_lock);
HFSPLUS_I(inode).flags = 0;
HFSPLUS_I(inode).flags = 0; HFSPLUS_I(inode).rsrc_inode =
NULL;
HFSPLUS_I(inode).rsrc_inode = NULL;+
atomic_set(&HFSPLUS_I(inode).opencnt, 0);
+ atomic_set(&HFSPLUS_I(inode).opencnt, 0);
if (inode->i_ino >= HFSPLUS_FIRSTUSER_CNID) {
read_inode:
Caveat: I'm no expert on filesystems (I thought a bit of bug-squishing
would be a learning experience), and this is my first post
to the kernel list, so feel free to flame me gently if this is wrong...
Peter Wainwright
The information contained within this email and any attachments
is confidential and intended solely for the attention and use of
the named addressee(s). It may not be disclosed to any other
person without the express authority of the HPA, the intended
recipient, or both.
If you are not the intended recipient, you must not disclose,
copy, distribute or retain this message or any part of it.
This footnote also confirms that this e-mail has been scanned
for computer viruses, but please re-scan any attachments before
opening or saving them.
Web site: http://www.hpa.org.uk
--------------------------------------------
On Monday 24 October 2005 05:58 am, Peter Wainwright wrote:
> >Hi Roman,
> >
> >I am using hfsplus (journalled) to mount a 10Gb partition on an usb
> >attached disk. I then copy a 3.5Gb file to the partition, then umount,
> >and mount again, and then delete it, but the space occupied by the file
> >is not freed, and doing that two times in a row ends up filling up the
> >space and I get an error that there is no space left. Here are steps
>
> to
>
> >reproduce:
>
> I have had a similar experience with my (Mac) IPOD.
> I am using kernel-2.6.12 from Fedora Core 4 on x86, but it is
> just possible that this bug is still around in the latest
> development kernels.
> fsck_hfs reveals lots of temporary files accumulating in
> the hidden directory "\000\000\000HFS+ Private Data".
> According to the HFS+ documentation these are files which
> are unlinked while in use. However, there may be a bug in
> the Linux hfsplus implementation which causes this to happen
> even when the files are not in use. It looks like the
> "opencnt" field is never initialized as (I think) it should
> be in hfsplus_read_inode. This means that a file can appear
> to be still in use when in fact it has been closed. This patch
> seems to fix it for me:
>
> diff -U3 -r linux-2.6.12-old/fs/hfsplus/super.c
> linux-2.6.12/fs/hfsplus/super.c
> --- linux-2.6.12-old/fs/hfsplus/super.c 2005-06-17 20:48:29.000000000
> +0100
> +++ linux-2.6.12/fs/hfsplus/super.c 2005-10-23 21:15:24.000000000
> +0100
> @@ -50,6 +50,7 @@
> init_MUTEX(&HFSPLUS_I(inode).extents_lock);
> HFSPLUS_I(inode).flags = 0;
> HFSPLUS_I(inode).flags = 0; HFSPLUS_I(inode).rsrc_inode =
> NULL;
> HFSPLUS_I(inode).rsrc_inode = NULL;+
> atomic_set(&HFSPLUS_I(inode).opencnt, 0);
> + atomic_set(&HFSPLUS_I(inode).opencnt, 0);
> if (inode->i_ino >= HFSPLUS_FIRSTUSER_CNID) {
> read_inode:
>
> Caveat: I'm no expert on filesystems (I thought a bit of bug-squishing
> would be a learning experience), and this is my first post
> to the kernel list, so feel free to flame me gently if this is wrong...
> Peter Wainwright
>
Hi,
One, your mailer ate the patch. Please attach or make sure your mailer isn't
wrapping lines. Two, try to CC the appropriate maintainer or else this patch
will probably get lost in the noise.
Consider yourself lightly flamed :)
--
Eric