4 ms·

That takes me back. In the WinNT 4.0 days my NTFS hard drive would become so heavily fragmented that it would take Explorer over a minute to display folder lis

That takes me back. In the WinNT 4.0 days my NTFS hard drive would become so heavily fragmented that it would take Explorer over a minute to display folder listing as it hunted around for file icons and other metadata. And then Explorer would randomly decide to rebuild its icon cache a freeze up for another minute. The built-in defragmenter did nothing to improve things. Our idiot IT guy said I should compile less often. I had to resort to WINFILE to do anything with the file system, at least until I convinced my boss to get me a Norton Speed Disk license. And yet when Win2K came around I refused to upgrade. It'll be too slow and buggy, I figured.

jaclaz 9y ago
>The built-in defragmenter did nothing to improve things. There was NO built-in defragmenter in Windows NT 4.0, it came first in Windows 2000.
- abdulhaq 9y ago
  Jerry pournelle used to rave about the golden bow defragger
  - jaclaz 9y ago
    >Jerry pournelle used to rave about the golden bow defragger Yes, that would be (for those not familiar with the matter) Vopt, the article on Wikipedia quotes Jerry Pournelle: https://en.wikipedia.org/wiki/Vopt https://en.wikipedia.org/wiki/Vopt Now (since early 2016) "abandonware/free" for all: https://web.archive.org/web/20160816083906/http://www.goldenbow.com/nudownload.htm https://web.archive.org/web/20160816083906/http://www.golden...
- Rhinobird 9y ago
  That would explain why it didn't do anything.
- thought_alarm 9y ago
  Diskeeper Lite was what I had in mind. It didn't defrag the directories.
  - jaclaz 9y ago
    >Diskeeper Lite was what I had in mind. It didn't defrag the directories. And in any case was not built-in. In Windows 2000 the built-in defragger was actually a "stripped down" version of Diskkeeper, maybe you are confusing NT 4.0 with Windows 2000? Some references here: https://msfn.org/board/topic/131017-msoft-uses-diskeeper-as-their-defrag-tool-trying-to-resize-partition/?do=findComment&comment=841932 https://msfn.org/board/topic/131017-msoft-uses-diskeeper-as-...
qubex 9y ago
I always thought NTFS was declared to be relatively immune from fragmentation problems. That’s why there was no in-built defragmenting tool for NTFS-formatted drives until much later on.
- executesorder66 9y ago
  NTFS is the only filesystem I've ever had to defrag.
  - dspillett 9y ago
    Either you never used FAT* or were very very lucky! It (and other old, naive, filesystems) used a pure first-available-block strategy that almost invites pathological fragmentation especially in a multi tasking (or worse, multi-user) environment. Also, I've seen ext* filesystems just as badly fragmented as NTFS ones in similar environments. One key problem I've seen on NTFS volumes in the past is with those that were converted from FAT (IIRC old Windows NT installations would do this even for fresh installs: install on FAT* for the first stage then convert to NTFS before the second) - the conversion process didn't move files around when converting to 4KByte blocks from larger ones so left a small chunk of free space after every file.
    - executesorder66 9y ago
      I've used FAT32, and yeah. I guess I got lucky. > Also, I've seen ext* filesystems just as badly fragmented as NTFS ones in similar environments. What kind of environment is that? I've rewritten terabytes of data over the same blocks, and never had any issues.
      - dspillett 9y ago
        > rewritten terabytes of data over the same blocks It isn't about the amount of data throughput or the reuse of blocks: it is how files are allocated space as they grow, particularly when there is concurrent activity, and how free space fragments as files shrink or, more likely, are removed. > What kind of environment is that? Busy near-full write-heavy multi-user file servers particularly. Multitasking exacerbates the "how files grow" issue, multiple users exacerbates both, and multiple concurrent users multiplies the issue further, being near full means that data fragmentation countermeasures are circumvented because due to worsened free-space fragmentation (all the space left is in small units). Ignoring a few pathological cases (that are usually unrealistic thought experiments), if the filesystem never gets particularly full then neither NTFS nor ext* are likely to fragment significantly. But in the circumstances mentioned above both are just as likely to. Their key mechanic for avoiding data fragmentation (keeping some free space after files where possible to allow for growth) is very similar, other technicalities where they vary more widely (like storing small objects in directory structures directly or the MFT) have an effect, but a much smaller effect than that attributable to the methods they share. Of course even some near-full multi-use volumes aren't going to fragment significantly at the filesystem level. If a volume is hosting large database files then they are likely to be reasonably contiguous from the filesystem's point of view and fragmentation issues within the data files is massively more significant. Also if most of your concurrent users are only reading (perhaps a media archive system maintained my a small team, perhaps one person, or just at most one person at any given time usually, but accessed by many?) they can be ignored from a fragmentation PoV (readers aren't going to affect data layout unless you have active writers and some exotic MVCC arrangement going on at the filesystem level).
jpalomaki 9y ago
Explorer performance issues have become one of my top annoyances in Windows 10. There's so many apps what want to hook themselves to provide context menu items, icon overlays or something else. If these apps are not responding in timely manner, Explorer gets really slow and figuring out the cause is not straightforward.
- youseecomrade 9y ago
  https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns https://docs.microsoft.com/en-us/sysinternals/downloads/auto...

jaclaz 9y ago

>The built-in defragmenter did nothing to improve things. There was NO built-in defragmenter in Windows NT 4.0, it came first in Windows 2000.

abdulhaq 9y ago
Jerry pournelle used to rave about the golden bow defragger
- jaclaz 9y ago
  >Jerry pournelle used to rave about the golden bow defragger Yes, that would be (for those not familiar with the matter) Vopt, the article on Wikipedia quotes Jerry Pournelle: https://en.wikipedia.org/wiki/Vopt https://en.wikipedia.org/wiki/Vopt Now (since early 2016) "abandonware/free" for all: https://web.archive.org/web/20160816083906/http://www.goldenbow.com/nudownload.htm https://web.archive.org/web/20160816083906/http://www.golden...
Rhinobird 9y ago
That would explain why it didn't do anything.
thought_alarm 9y ago
Diskeeper Lite was what I had in mind. It didn't defrag the directories.
- jaclaz 9y ago
  >Diskeeper Lite was what I had in mind. It didn't defrag the directories. And in any case was not built-in. In Windows 2000 the built-in defragger was actually a "stripped down" version of Diskkeeper, maybe you are confusing NT 4.0 with Windows 2000? Some references here: https://msfn.org/board/topic/131017-msoft-uses-diskeeper-as-their-defrag-tool-trying-to-resize-partition/?do=findComment&comment=841932 https://msfn.org/board/topic/131017-msoft-uses-diskeeper-as-...

qubex 9y ago

I always thought NTFS was declared to be relatively immune from fragmentation problems. That’s why there was no in-built defragmenting tool for NTFS-formatted drives until much later on.

executesorder66 9y ago
NTFS is the only filesystem I've ever had to defrag.
- dspillett 9y ago
  Either you never used FAT* or were very very lucky! It (and other old, naive, filesystems) used a pure first-available-block strategy that almost invites pathological fragmentation especially in a multi tasking (or worse, multi-user) environment. Also, I've seen ext* filesystems just as badly fragmented as NTFS ones in similar environments. One key problem I've seen on NTFS volumes in the past is with those that were converted from FAT (IIRC old Windows NT installations would do this even for fresh installs: install on FAT* for the first stage then convert to NTFS before the second) - the conversion process didn't move files around when converting to 4KByte blocks from larger ones so left a small chunk of free space after every file.
  - executesorder66 9y ago
    I've used FAT32, and yeah. I guess I got lucky. > Also, I've seen ext* filesystems just as badly fragmented as NTFS ones in similar environments. What kind of environment is that? I've rewritten terabytes of data over the same blocks, and never had any issues.
    - dspillett 9y ago
      > rewritten terabytes of data over the same blocks It isn't about the amount of data throughput or the reuse of blocks: it is how files are allocated space as they grow, particularly when there is concurrent activity, and how free space fragments as files shrink or, more likely, are removed. > What kind of environment is that? Busy near-full write-heavy multi-user file servers particularly. Multitasking exacerbates the "how files grow" issue, multiple users exacerbates both, and multiple concurrent users multiplies the issue further, being near full means that data fragmentation countermeasures are circumvented because due to worsened free-space fragmentation (all the space left is in small units). Ignoring a few pathological cases (that are usually unrealistic thought experiments), if the filesystem never gets particularly full then neither NTFS nor ext* are likely to fragment significantly. But in the circumstances mentioned above both are just as likely to. Their key mechanic for avoiding data fragmentation (keeping some free space after files where possible to allow for growth) is very similar, other technicalities where they vary more widely (like storing small objects in directory structures directly or the MFT) have an effect, but a much smaller effect than that attributable to the methods they share. Of course even some near-full multi-use volumes aren't going to fragment significantly at the filesystem level. If a volume is hosting large database files then they are likely to be reasonably contiguous from the filesystem's point of view and fragmentation issues within the data files is massively more significant. Also if most of your concurrent users are only reading (perhaps a media archive system maintained my a small team, perhaps one person, or just at most one person at any given time usually, but accessed by many?) they can be ignored from a fragmentation PoV (readers aren't going to affect data layout unless you have active writers and some exotic MVCC arrangement going on at the filesystem level).

jpalomaki 9y ago

Explorer performance issues have become one of my top annoyances in Windows 10. There's so many apps what want to hook themselves to provide context menu items, icon overlays or something else. If these apps are not responding in timely manner, Explorer gets really slow and figuring out the cause is not straightforward.

youseecomrade 9y ago
https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns https://docs.microsoft.com/en-us/sysinternals/downloads/auto...