 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 13 Nov 2007 08:32:14 -0800, Darren New wrote:
> Jim Henderson wrote:
>> On Mon, 12 Nov 2007 20:38:07 -0800, Darren New wrote:
>>
>>> Open the file, write a little bit, close it. Open it again, append a
>>> little, close it. Repeat. Possibly it requires other people to also
>>> have the file open at the same time, as for reading or something?
>>
>> Don't think so.
>
> I don't know. All I can say is that I've seen files with 2K length
> spread over half a dozen blocks as reported by defrag. :-) I'm not sure
> what causes it.
At a guess, corruption. :-)
> Try running the defrag GUI version, look at the report, and see if
> things like your registry hives or event logs are fragmented and how
> much. In my expereince, it's not uncommon.
Hmmm, well, the only Windows I have installed is in VMware with virtual
disks, so I'm unlikely to run across this, I think.
>> Sparse files I could see, but a proper sparse file
>> wouldn't shrink during a defrag, either, based on my own experiences,
>> because the "empty" space is as important as the real data is to the
>> application.
>
> Yah. Sparse files are already deallocated, so you can't really
> deallocate more.
Yep.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 13 Nov 2007 08:37:37 -0800, Darren New wrote:
> I mean, 43 fragments for a 1K ntuser.dat? 15 fragments for a 1K
> default.log? In a 4K cluster size? Clearly, there has to be fragmented
> files with not-fully-packed blocks, if defrag is to be believed.
Weird. Though based on my experiences with Active Directory, I'm not
inclined to believe what any Microsoft utility tells me. I've seen two
different hardware diagnostics point fingers at each other, but with
Windows 2000 Server, I had a first - two programs that were intended to
tell me the health of my domain that couldn't agree with each other.
Both from the same vendor.
> Maybe that's the problem tho - the layout is right, the reporting is
> funky.
Could be.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v7 wrote:
>> The allocation engine allocates a full block to a file, and does not
>> allocate any additional ones until the present ones are full.
>
> How do you know?
Well, put it this way: This is a trivial algorithm, and there is
absolutely no *reason* why it would do anything different, so...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson nous apporta ses lumieres en ce 2007/11/12 19:37:
> On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:
>
>> Ever heard of "sparse" files?
>
> Yes. Old hand at NetWare; didn't know that Windows filesystems supported
> sparse files.
>
> Jim
Was even supported under DOS 3, maybe earlier.
--
Alain
-------------------------------------------------
Always try to be modest, and be proud of it!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez nous apporta ses lumieres en ce 2007/11/13 12:41:
> Darren New escribió:
>> Unlike UNIX, it's not just a matter of seeking around. You have to
>> open the file as a sparse file, then you have to say "hey, this area
>> is sparse" rather than (say) just writing all zeros to the blocks or
>> something.
>
> Not really... Cross-platform programs that don't use any
> Windows-specific API manage to create sparse files here. That's why
> download managers that download in chunks give the option to
> pre-allocate: sparse files that are filled randomly get fragmented quite
> badly.
And can have TONS of slack space! Just imagine a file whose records are about 64
bytes each, and only having less than 0.01% of them actualy used... with
clusters of 4Kb. You are stuck with many clusters containing only 1 record, at
some random location in the cluster.
--
Alain
-------------------------------------------------
Moonies: Only really happy shit happens.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 nous apporta ses lumieres en ce 2007/11/12 13:58:
> Darren New wrote:
>> M_a_r_c wrote:
>>> "Nicolas Alvarez" <nic### [at] gmail isthebestcom> a écrit
>>> dans le message de news: 473472c5$1@news.povray.org...
>>>> Fa3ien escribió:
>>>>> I've run a defrag, which freed 250 Mb.
>>>> Defrags free disk space??
>>>
>>> I am not an expert but maybe if it optimizes disk occupation by
>>> filling blocks instead of letting empty portions of blocks.
>>
>> More precisely, if you have a fragmented file taking 3 blocks and
>> filling them each only 10%, defragging that file will free two blocks.
>
> More precisely, how would this situation arrise in the first place?
>
> The allocation engine allocates a full block to a file, and does not
> allocate any additional ones until the present ones are full.
>
How can you assume that it only allocate a single block? NTFS allocate some
cluster when you create a new file in an attempt to reduce fragmentation that
appens when several files are created at once and randomly filled. Once the file
is closed, the unused clusters are liberated. It does the same when all the
file's alocated space is filled ant it need some more disk space. That
prealocated space must reside in successive clusters.
--
Alain
-------------------------------------------------
Fix reason firmly in her seat, and call to her tribunal every fact, every
opinion. Question with boldness even the existence of a God; because, if
there be one, he must more approve of the homage of reason, than that of
blindfolded fear.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain escribió:
> Nicolas Alvarez nous apporta ses lumieres en ce 2007/11/13 12:41:
>>
>> Not really... Cross-platform programs that don't use any
>> Windows-specific API manage to create sparse files here. That's why
>> download managers that download in chunks give the option to
>> pre-allocate: sparse files that are filled randomly get fragmented
>> quite badly.
> And can have TONS of slack space! Just imagine a file whose records are
> about 64 bytes each, and only having less than 0.01% of them actualy
> used... with clusters of 4Kb. You are stuck with many clusters
> containing only 1 record, at some random location in the cluster.
>
Of course. The file usage on disk grows while it gets downloaded. But in
the end, it will eventually be totally downloaded and extremely
fragmented. So in those cases it's a good idea to pre-allocate. If you
will have lots of "unused records" for long periods, then yes it's a
good idea to let it use sparse files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
>> Unlike UNIX, it's not just a matter of seeking around. You have to
>> open the file as a sparse file, then you have to say "hey, this area
>> is sparse" rather than (say) just writing all zeros to the blocks or
>> something.
>
> Not really... Cross-platform programs that don't use any
> Windows-specific API manage to create sparse files here.
I think if you write to it, regardless of what you write, you get
allocated space. UNIX *used* to see an all-zeros buffer and say "Gee, we
don't need to write that." You didn't have to seek over the sparse
space to make it sparse, IIRC.
I think the calls I'm thinking of are for making an existing data area
sparse, too; i.e., throwing away the beginning of a log file without
changing offsets of existing records. And you may even need to open the
file in "sparse" mode.
Or, I could be completely wrong. This one I never actually did. :-)
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> Jim Henderson nous apporta ses lumieres en ce 2007/11/12 19:37:
>> On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:
>>
>>> Ever heard of "sparse" files?
>>
>> Yes. Old hand at NetWare; didn't know that Windows filesystems
>> supported sparse files.
>>
>> Jim
> Was even supported under DOS 3, maybe earlier.
What, on FAT? Nah. Would have to be some other format, cause FAT
doesn't have the data structures for that.
CP/M did, actually, now that I think of it. :-)
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Darren New escribió:
>> I mean, 43 fragments for a 1K ntuser.dat?
>
> That's probably mis-reporting the size. NTUSER.DAT has the whole user
> registry hive. It's 6MB on my machine, no way it can be 1K on yours.
Yah, OK. Looking at it with DIR is 15 meg or so here. I *thought* that
was kind of funky.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
