Re: atomicity

Re: atomicity

[Tim Smith]

On Sat, 5 Dec 1998, Alan Cox wrote:
> With ext2fs you should never need a defragmenter

Unless I've accidently run my portable (written in straight ANSI C...works on
Unix, Windows, and Mac!) file system fragmenter on it.

Basic algorithm to create a highly fragmented file on pretty much any
file system:

	while file system not full
		create random small files
	delete one of them
	open target file for writing
	while target file not fully written
		write until error
		delete one of the small files at random
	close target file
	delete all of the small random files that remain

Are there any file systems around that will manage to resist fragmentation
if subjected to that?

(No, I'm not insane.  I wrote a fragmenter so I could test a Mac background
defragmenter I wrote).

--Tim Smith


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: atomicity

[Rogier Wolff]

Alan Cox wrote:
> Think about it this way. SIGKILL and a power failure are identical.

Well, I occasionally get processes stuck in "D" state. SIGKILL doesn't
kill them, a power failure does. (Try a filesystem that Oops-es on the
"mount" system call, then retry the mount). 

Yeah, I know I've taken your quote out of context. Sorry. :-)

				Roger. 

-- 
My pet light bulb is a year old today.   \_________  R.E.Wolff@BitWizard.nl
That's 5.9*10^12 miles. Your mileage will NOT vary.\__Phone: +31-15-2137555
--(time <-> distance can be converted: lightspeed)--  \____ fax: ..-2138217
We write Linux device drivers for any device you may have! \_______________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: atomicity

[Alan Cox]

> 	open target file for writing
> 	while target file not fully written
> 		write until error
> 		delete one of the small files at random
> 	close target file
> 	delete all of the small random files that remain
> 
> Are there any file systems around that will manage to resist fragmentation
> if subjected to that?

ext2fs will quite happily handle that situation (in fact its not an atypical
pattern of I/O on a big multiuser box - consider someone doing a download
as another user does an rm -r.

ext2fs tries to grab linear chunks of disk and divides the disk into cylinder
groups to also help to maintain locality. The BSD ffs papers [McKusik et al]
describe this sort of stuff well.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/