On 4/12/05 at 5:58 PM, Ben Kennedy ([EMAIL PROTECTED]) said: >On 12 4 2005 at 5:51 pm -0400, Steve Abrahamson wrote: > >>I have some concern about my database and fragmentation. My message >>database is about 500 megs (when I compact it it goes down to 200-250 >>megs). But when I look at my disk fragmentation, my message database is >>(before compacting), over 1,600 fragments. And I'm thinking, gee, maybe >>PM's spending way too many cycles managing disk access. > >PM doesn't manage file fragments; you'll have to speak to the filesystem >about that. :) > >How do you determine the fragmentation? I'd be curious (academically) to >see how mine fares. > >Are you saying that doing a Compact doesn't result in a mostly >unfragmented DB?
See below.. >>The question is what to do about that. The database is open all the time. >>OS X 10.3's journaled file system should be able to defragment files, and >>it seems that it does a reasonably decent job of that, but it only gets >>to do that when the file is opening (I think). If the database is always >>open, it's just going to keep writing and writing and writing, and it's >>going to get hideously fragmented. > >The auto-defragmentation thing only happens for small files (something on >the order of 10 MB I think but I forget offhand). Google the technote >for details. Ah. That'd make sense - you'd want it to be largely invisible to the user, and with larger files there'd be a bigger lag. >>Wondering aloud, might there be some way for PM to encourage the OS to >>keep it's database less fragmented? Some routine that poked the OS to >>"maintain file <xyz>" during 3am OS housekeeping tasks? > >How about a cron job which copies the file to a temp file, deletes the >original, and renames? If you have sufficient free space for the target >file, it should end up mostly defragmented by virtue of recreating it. >Or so I would expect. Again, below. >>Alternately, why am I experiencing a problem where others are not, what's >>the difference, and what behavioral changes can I make here to match >>those who are not having a problem? > >This is a better question -- I suspect that the fragmentation thing is a >red herring. Well, yes and no. I found an app on VersionTracker called iDefrag, and downloaded a demo: <http://www.coriolis-systems.com/demos/iDefrag%20Demo.dmg> It analyzes the drive, and reports the typical information: graphical representation of the drive, fragmentation percentages, and a list of fragmented files sorted from most to least. The full (non-demo) version actually does something about this, though by the VT notes, TechTool sounds like it might be better. And I thought I wouldn't have to defrag anymore. What I found was that most of the files of the first 1024 reported were 2 fragments, then a lot of three. It was only the top 30 or so that were highly fragmented, and they were mostly mp3s and other noncritical stuff. There were a few with fragments in the hundreds, and then at the top sat my mail database at over 1,600 fragments. You don't think there'd be some overhead associated with managing 1,600+ fragments, do you? Nah. I did a database compact, and the new database had 1,200+ fragments. Better, but not much. I decided that the Finder might be smarter about laying a file down than any app would likely be, so I did a simple Finder copy of the new compacted database. 400+. Copied again. 250+. I went with that one, and indeed, PM got noticeably better, but not for long; within a day it'd started to lag again. So the Finder seems to have some better inside knowledge of disk usage, and that's good to know for manual tweaking. Compacting a database on a cleaner drive than mine might also result in more contiguous file, so my drive state might be a contributing factor here. Still, the fact that my message database was the only thing in my (single-drive single-volume) system that was even close to that fragmented says something to me... if you think about it, the file is open all the time, being written to constantly through the day, gets new data trickling in all day long, every day - of course it's going to be the most fragmented thing there. It's got exponentially more writes than any other file, and that's perfectly expected use. Should a mail app be expected to take more responsibility than other apps for the state of it's file? Can it? I don't know either, but it's an interesting question, at least. Steve Steve Abrahamson Ascending Technologies FileMaker 7 Certified Developer http://www.asctech.com [EMAIL PROTECTED]
