dce@Solbourne.COM (David Elliott) (08/09/89)
Assume I have an 8k/1k filesystem and create a file with 789
bytes in it. This gives me one fragment.
Now, let's say I add to the file so it grows to be 3875 bytes,
taking 4 fragments, and that these fragments are not all in
the same block.
OK, let's increase the file size to 10486 bytes, which is 11
fragments.
At this point, is the data moved on the disk so that my file
comprises one block and 3 fragments, or is it left as fragments?
(Note: In the above, assume that the file changes have taken
place far enough apart so that the files have been written to disk
in between.)
When do entire blocks get written? Only when the entire
block is written at once (i.e., when the buffer cache gets
flushed)? Do new files tend to get placed in available blocks,
or do they go in partially-used blocks?
--
David Elliott dce@Solbourne.COM
...!{uunet,boulder,nbires,sun}!stan!dce
"I had a dream that my kids had been reparented." - Tom LaStrangechris@mimsy.UUCP (Chris Torek) (08/10/89)
In article <1886@marvin.Solbourne.COM> dce@Solbourne.COM (David Elliott) writes: >Assume I have an 8k/1k filesystem and create a file with 789 >bytes in it. This gives me one fragment. Good so far. >Now, let's say I add to the file so it grows to be 3875 bytes, >taking 4 fragments, and that these fragments are not all in >the same block. Not possible. All fragments are always in the same block. >OK, let's increase the file size to 10486 bytes, which is 11 >fragments. > >At this point, is the data moved on the disk so that my file >comprises one block and 3 fragments, or is it left as fragments? The file will occupy one block and 3 fragments-within-one-block. The exact mechanism by which a fragment expands, or becomes a block, depends on which version of 4BSD and on how many blocks and fragments are free and on whether the process is `well-behaved' when it comes to writing files. (A well-behaved process writes full blocks on full-block boundaries. This is most common, although in 4.2BSD [but not 4.3BSD] /usr/ucb/vi was ill-behaved, writing 1K at a time.) >Do new files tend to get placed in available blocks, >or do they go in partially-used blocks? A new fragment (for a file where no fragments existed before) is always placed in an existing fragmented block, if any, within the appropriate cylinder group. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mckee@hpfcdc.HP.COM (Bret McKee) (08/11/89)
>Assume I have an 8k/1k filesystem and create a file with 789 >bytes in it. This gives me one fragment. > >Now, let's say I add to the file so it grows to be 3875 bytes, >taking 4 fragments, and that these fragments are not all in >the same block. This is an impossible setup. You would have one file taking up a 4k "fragment". At most, a file will occupy one incomplete block. --- Bret Mckee Hewlett Packard HP-UX Development Lab Phone:(303)229-6116 email: mckee@hpfcls or mckee%hpfcde@hplabs.hp.com Of course, these are just my opinions...
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (08/17/89)
? From: Chris Torek <chris@mimsy.uucp>
? In article <1886@marvin.Solbourne.COM> dce@Solbourne.COM (David Elliott)
? writes:
? >OK, let's increase the file size to 10486 bytes, which is 11
? >fragments.
? >
? >At this point, is the data moved on the disk so that my file
? >comprises one block and 3 fragments, or is it left as fragments?
? The file will occupy one block and 3 fragments-within-one-block.
? The exact mechanism by which a fragment expands, or becomes a
? block, depends on which version of 4BSD and on how many blocks
? and fragments are free and on whether the process is `well-behaved'
? when it comes to writing files. (A well-behaved process writes
? full blocks on full-block boundaries. This is most common,
? although in 4.2BSD [but not 4.3BSD] /usr/ucb/vi was ill-behaved,
? writing 1K at a time.)
OK, trick question for wizards! How many fragments does a file of
size ((1 << 20) + 1) have? Answer: zero! Only direct blocks are
fragmented! Top of page 208 in the 4.3 book.
Chris, was this true in 4.2 as well?
? In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
? Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
Root Boy Jim
Have GNU, Will Travel.grr@cbmvax.UUCP (George Robbins) (08/17/89)
In article <20630@adm.BRL.MIL> rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: > > OK, trick question for wizards! How many fragments does a file of > size ((1 << 20) + 1) have? Answer: zero! Only direct blocks are > fragmented! Top of page 208 in the 4.3 book. > > Chris, was this true in 4.2 as well? Given that the main purpose of framentation is to reduce the percentage of disk space wasted by itsy-bitsy files as compared to simply increasing the block size, this is hardly cause for distress... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
chris@mimsy.umd.edu (Chris Torek) (08/18/89)
In article <8908162031.AA09888@dsys.ncsl.nist.gov> (probably changed IDs at brl, though; alas) <rbj@dsys.ncsl.nist.gov> writes: >OK, trick question for wizards! How many fragments does a file of >size ((1 << 20) + 1) have? Answer: zero! Only direct blocks are >fragmented! Top of page 208 in the 4.3 book. Right. >Chris, was this true in 4.2 as well? Unless it was a bug fix or performance hack---and there were only a few of those---most anything in the file system code itself that is in 4.3BSD is also in 4.2BSD. Kirk did a good job on that code. (Some of the other sections of the 4.2BSD were a bit skunky :-) [but maybe they were not Kirk's code...]) Chris