* Re: Linux slack space question
2006-12-08 17:21 Linux slack space question Maria Short
2006-12-08 17:46 ` Bob Copeland
@ 2006-12-08 18:51 ` linux-os (Dick Johnson)
2006-12-11 17:30 ` Erik Mouw
2 siblings, 0 replies; 4+ messages in thread
From: linux-os (Dick Johnson) @ 2006-12-08 18:51 UTC (permalink / raw)
To: Maria Short; +Cc: linux-kernel
On Fri, 8 Dec 2006, Maria Short wrote:
> I have a question regarding how the Linux kernel handles slack space.
> I know that the ext3 filesystems typically use 1,2 or 4 KB blocks and
> if a file is not an even multiple of the block size then the last
> allocated block will not be completely filled, the remaining space is
> wasted as slack space.
>
Not wasted, could be extended if additional data are written.
> What I need is the code in the kernel that does that. I have been
> looking at http://lxr.linux.no/source/fs/ext3/inode.c but I could not
> find the specific code for partially filling the last block and
> placing an EOF at the end, leaving the rest to slack space.
An EOF? Unlike CP/M the Linux file-systems copy to user-space up to the
last byte written to the file, not up to the last block. Therefore, there
is no need for "fill" and certainly no EOF character. All Linux/Unix
files are binary files, i.e., there are no special characters inserted.
Now, when you read a file using buffered I/O (the f***() functions), the
'C' runtime library converts I/O so that functions like feof(*stream) work.
The actual EOF on a binary file occurs when a read() returns 0 bytes.
The number of bytes actually written to files are handled in inodes. In fact,
you can make a file larger simply by moving a file-pointer. That changes
the inode value. Such files are called sparse files and, when read, the space
not written is cleared so the user never reads something that wasn't
specifically written.
>
> Please forward the answer to mgolod@ieee.org as soon as possible.
>
> Thank you very much.
> -
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.68 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux slack space question
2006-12-08 17:21 Linux slack space question Maria Short
2006-12-08 17:46 ` Bob Copeland
2006-12-08 18:51 ` linux-os (Dick Johnson)
@ 2006-12-11 17:30 ` Erik Mouw
2 siblings, 0 replies; 4+ messages in thread
From: Erik Mouw @ 2006-12-11 17:30 UTC (permalink / raw)
To: Maria Short; +Cc: linux-kernel
On Fri, Dec 08, 2006 at 12:21:04PM -0500, Maria Short wrote:
> I have a question regarding how the Linux kernel handles slack space.
> I know that the ext3 filesystems typically use 1,2 or 4 KB blocks and
> if a file is not an even multiple of the block size then the last
> allocated block will not be completely filled, the remaining space is
> wasted as slack space.
>
> What I need is the code in the kernel that does that. I have been
> looking at http://lxr.linux.no/source/fs/ext3/inode.c but I could not
> find the specific code for partially filling the last block and
> placing an EOF at the end, leaving the rest to slack space.
Think about it: what value would an EOF have if all byte values are
allowed in a file?
>From the very first Unix filesystem an inode contains both the number
of blocks it contains and the actual file size.
> Please forward the answer to mgolod@ieee.org as soon as possible.
Hmm no. You asked a public forum so the reply will go to that same
public forum. See http://catb.org/esr/faqs/smart-questions.html#noprivate .
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply [flat|nested] 4+ messages in thread