Re: File Fragmentation
- From: Cliff Hewitt <somebug@xxxxxxxxxxxxxx>
- Date: Tue, 06 Dec 2005 05:15:36 GMT
Peter T. Breuer wrote:
You don't seem to get it; the scenario you paint only has meaning for msdos - there is no "next fragment" any more than there is a "next file". That is because you are picturing a single unbuffered thread of control as running the o/s, while the opposite is the case: the o/s gives the illusion of a unique thread of control to each of (consults own system) 100+ buffered processes simultaneously.
What the o/s sees is one hundred processes running for a small timeslice then pausing in i/o while it swaps in another process, which asks for i/o and is replaced by another process, etc. Those i/o requests are satisfied from _buffers_, not from disk! Requests that fall through the buffer search unsatisfied are queued for the disk from ALL processes, and are satisfied from time to time as the o/s decides. Each set of outstanding requests is satisfied in a single "elevator" sweep across the disk, and each request is accompanied by read ahead of a few dozen blocks beynd the requested point, just in case.
Thus buffers are populated with the fragments of _other_ files and that of their own selves that lie close to them on disk. And the elevator must traverse the disk in any case in rder to satisfy the unrelated pick-up requests from many different processes! Your sendmail is scanning its outbound queue and your logger is writing to /var at the same time as you are reading a man page!
The sum of this is "thre is no next fragment".
Peter
Believe me, I understand fragments. Yes, I understand them the MS-DOS way, I understand them theoretically, and I see them on my ext3 partitions. I don't study them actively, but I understand them. What you describe is done at the hardware level, but the file system has control over where the fragments are placed, how the files are distributed on the hard disk. If *that* was done in hardware, we'd have no need for software-implementations of file systems, like ext2, NTFS, etc.
The way we as users look at files, you are right, there is no next fragment if the file system does its job well. That doesn't explain the inner workings. Saying the disk read/write head sweeps the surface of the platter explains hardware that I already know (there are many algorithms that do this), and putting data into buffers and signalling interrupts is again stuff I already know (most modern-day hardware does this).
Currently, I think your explanation on clustering blocks is the best one suited for my original question. I appreciate the time you've taken to help me understand it.
Thanks again,
Cliff Hewitt .
- Follow-Ups:
- Re: File Fragmentation
- From: prg
- Re: File Fragmentation
- From: Peter T. Breuer
- Re: File Fragmentation
- References:
- File Fragmentation
- From: Cliff Hewitt
- Re: File Fragmentation
- From: stan
- Re: File Fragmentation
- From: Cliff Hewitt
- Re: File Fragmentation
- From: Peter T. Breuer
- Re: File Fragmentation
- From: Cliff Hewitt
- Re: File Fragmentation
- From: Peter T. Breuer
- File Fragmentation
- Prev by Date: which process (ID) occupies the disk most
- Next by Date: Re: which process (ID) occupies the disk most
- Previous by thread: Re: File Fragmentation
- Next by thread: Re: File Fragmentation
- Index(es):
Relevant Pages
|