<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>RE: [Ocfs2-users] Free space oddities on OCFS2</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Thanks for the info, but I still don't understand if this is a normal behaviour or not.<BR>
<BR>
For me, at least, it's not very useful if the global bitmap is 6 times larger than the data I'm putting on it, and after deleting everything, this bitmap doesn't decrease in size.<BR>
<BR>
Regards,<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Sunil Mushran [<A HREF="mailto:Sunil.Mushran@oracle.com">mailto:Sunil.Mushran@oracle.com</A>]<BR>
Sent: Wed 8/2/2006 8:19 PM<BR>
To: Robinson Maureira Castillo<BR>
Cc: ocfs2-users@oss.oracle.com<BR>
Subject: Re: [Ocfs2-users] Free space oddities on OCFS2<BR>
<BR>
1. The global bitmap in ocfs2 maps all the clusters on the disk. That<BR>
includes,<BR>
the space used by the super block, root dir, system dir, system files, etc.<BR>
Hence the usage on a clean fs. Most of this space is being used by the<BR>
journals.<BR>
# echo "stat //journal:0000" | debugfs.ocfs2 -n /dev/sdX<BR>
<BR>
2. ocfs2 does not preallocate space for inodes. It allocates space on<BR>
demand.<BR>
You can view the space allocated to inodes for slot 0 as follows:<BR>
# echo "stat //inode_alloc:0000" | debugfs.ocfs2 -n /dev/sdX<BR>
<BR>
3. du does not reflect space used by filesystem metadata.<BR>
</FONT>
</P>
</BODY>
</HTML>