Defragging Picasa *.db files

[slender]

Hi,
I´m just testing this wonderful piece of software and now wondering what files would be good to add to my default space hog list.

I have Picasa installed on my c-drive and its databases are located in application data directory. There is about 3 different *.db files which are quite big ~1gb. Problem is that these files are mentioned in boot optimize file so they are processed after directory defragment in fast update. Of course i could delete files/lines from boot optimize file (layout.ini?), but i have to check this file every time mydefrag is executed. So what would be more sophisticated method?

It would be great to put *.db files on their own zone + 1% free because they grow every time i add pictures to picasa. Or is this bad idea?

Actually, even tough these files were on their own zone, will new data be added physically to the end of file or scattered across. If latter then its useless to add these files with extra space behind them? Or am i missing something?

[jeroen]

I am not sure what you are asking. I all sounds fine to me, I see no problems if you make an extra zone for the Picasa databases. That's what the MyDefrag scripts are all about, to give users a possibility to optimize their disk according to their wishes and specific situation.

[slender]

- I would like to put picasas db files to spacehog zone, but how? These files are prosessed on the bootoptimize sequence because they are mentioned in layout.ini. So basically how to include bootoptimize (layout.ini) so that i can exclude some specific files?

Additionally i was just wondering if there is any sense in my wish.
-I assume that after moving these files to spacehog zone my program files will be moved closer to my hard disk inner circle.

- If the database is not fragmented and there is physically empty space behind it, Will the hard-disk/operating system write new data physically after the fragment? If not, then is there any sense putting space behind these files?

[jonib]

- I would like to put picasas db files to spacehog zone, but how? These files are prosessed on the bootoptimize sequence because they are mentioned in layout.ini. So basically how to include bootoptimize (layout.ini) so that i can exclude some specific files?

In the script add And Not(FileName("*.db")) to the end of ImportListFromBootOptimize() to exclude it from the boot optimize zone, you can add other file types too, then the default spacehog settings would move them to the spacehogs zone.

Code:

ImportListFromBootOptimize() And Not(FileName("*.db"))

Additionally i was just wondering if there is any sense in my wish.
-I assume that after moving these files to spacehog zone my program files will be moved closer to my hard disk inner circle because of the freed space in that area.

Any big files that are not performance critical could be moved to the spacehog zone without problem and probably speed up the system a bit.

jonib

[SunBlade]

you may want to add more space hogs criterias to the boot optimize:

Code:

ImportListFromBootOptimize()
and not(
  Size(50000000,0)
  or (LastAccessEnabled(yes) and LastAccess(,1 month ago))
  or FileName("*.db")
  )

should slim down the boot optimize zone quite a lot

[jeroen]

should slim down the boot optimize zone quite a lot

Yes, but it will also make booting slower.

[slender]

Hmm. Taking those gigabyte database files off from zone 2 made my boot bit faster. For my case this was off course self-evident, but I'm not sure if the SunBlade additions make things any better. Windows should run scheduled boot/layout.ini defragment once in a awhile, but I don't really know how often that actually works.

On the other hand it makes sense that files that have not been accessed for a month are in wrong place if they are mentioned in layoyt.ini.

[jimbo]

On the other hand it makes sense that files that have not been accessed for a month are in wrong place if they are mentioned in layoyt.ini.

That depends on whether you have rebooted in the last month or not, really

Seriously though, why are people so hung up about boot time speed rather than throughout the day performance? Microsoft only do it because it makes for a snappy marketing metric "we shaved xxx seconds of boot time" (but once it is booted, everything is 10% slower).

Personally, I reboot maybe once a week. Saving 10 seconds off that time is seriously unlikely to compare to the performance hike I can get through 50 hours of operation if the file placements are optimised for normal running.

[jeroen]

Seriously though, why are people so hung up about boot time speed rather than throughout the day performance?

Good question, and I share the sentiment. I got a lot of questions about it for JkDefrag, it was by far the number 1 most requested feature. I also do not reboot that often, and regular performance is more important for me. My computer is always on because of watchdogs and downloads. But I know there are many people who turn their computer off every day, hobby computers, office computers, laptops. And the first thing they experience when wanting to use the computer again is a long wait for the computer to boot. It's a big annoyance.

[slender]

On the other hand it makes sense that files that have not been accessed for a month are in wrong place if they are mentioned in layoyt.ini.

That depends on whether you have rebooted in the last month or not, really

Seriously though, why are people so hung up about boot time speed rather than throughout the day performance? Microsoft only do it because it makes for a snappy marketing metric "we shaved xxx seconds of boot time" (but once it is booted, everything is 10% slower).

Personally, I reboot maybe once a week. Saving 10 seconds off that time is seriously unlikely to compare to the performance hike I can get through 50 hours of operation if the file placements are optimised for normal running.

Yep. I should have mentioned that i shut down my computer almost everyday. And for me its not all about boot speed. I wanted those spacehog files out from inner zones to end. After moving 50 Mb and greater files from my inner zone to last zone i got lots of program files to "much" closer my inner zones.

[jonib]

Seriously though, why are people so hung up about boot time speed rather than throughout the day performance? Microsoft only do it because it makes for a snappy marketing metric "we shaved xxx seconds of boot time" (but once it is booted, everything is 10% slower).

I boot up my primary "Work"(@home) computer at least once everyday, as it would be silly to keep two computers ON all the time, and it's a dual/multi-boot system as well so I need to reboot sometimes, so I feel the bootup time is the most useless time I have to wait so I want to minimize that, of course "throughout the day performance" is more important, but I want both.

Personally, I reboot maybe once a week. Saving 10 seconds off that time is seriously unlikely to compare to the performance hike I can get through 50 hours of operation if the file placements are optimised for normal running.

Well I have a server type computer that has a uptime of months, so my primary computer don't have to work all the time.

jonib

[cg]

I also have a server that runs all the time, but my desktop I boot up when I need it (which is most days).  So boot time on that machine is really important while I could care less about boot time on my server.

[poutnik]

Yep. I should have mentioned that i shut down my computer almost everyday. And for me its not all about boot speed. I wanted those spacehog files out from inner zones to end. After moving 50 Mb and greater files from my inner zone to last zone i got lots of program files to "much" closer my inner zones.

Little off topic - not all big files are same and should be treated by same way.

Frequently accessed database files have access patterns of small files,
i.e. there are reads/writes of small parts only, not the whole files
( as example index files of desktop search software ).

Placement such files at fast disk end is IMHO perfectly OK.

[SunBlade]

Little off topic - not all big files are same and should be treated by same way.
Frequently accessed database files have access patterns of small files, i.e. there are reads/writes of small parts only, not the whole files ( as example index files of desktop search software ).
Placement such files at fast disk end is IMHO perfectly OK.

yes. unfortunately the only way to determine the accessfrequency on files is to install a background service which logs all Disk activity. as you might imagine, the performance drop, will nullify any defragmentation gains.

all MyDefrag standard scripts are for normal users, with normal computers and normal needs.
so if you find something illogical like a 2GB database in your boot zone while not running a DB server, you should change your MyD script.
nobody is perfect, and even jeroen can't build a script for every possibility out there.
fortunately all humans are blessed with a brain, and since you already proved you're capable of using yours, i'm positive you will find the balance between boot speed and boot zone size for your system.

PS: i believe everything >50MB, deserves to be put in the last zone. exceptions: pagefile and registry (DOT).

[poutnik]

yes. unfortunately the only way to determine the accessfrequency on files is to install a background service which logs all Disk activity. as you might imagine, the performance drop, will nullify any defragmentation gains.

Fortunately there are more ways, based on knowledge what those files are.

all MyDefrag standard scripts are for normal users, with normal computers and normal needs.
so if you find something illogical like a 2GB database in your boot zone while not running a DB server, you should change your MyD script.

Yes, 2 GB is quite big, but 100-200MB are very common sizes of desktop search index files.
They are read and part of them written many times during day.
One need not to run DB server.
But, they are obviously processed much more frequently than picasa.db.

PS: i believe everything >50MB, deserves to be put in the last zone. exceptions: pagefile and registry (DOT).

I would say the way of file usage does matter more, than size.

Lets say there is a file 5MB, read the whole time by time. The access time is cca 1/10 of transfer time, so placement is not much critical by both access and transfer speed criteria, if not read often.

Lets say there is a file 80MB, read/write blocks 500 kB frequently.
Than block access takes cca the same as block transfer , so placement is important in both access and transfer criteria.
Lets say Registry files are good example as you already realized, with even smaller blocks.

Concerning pagefile, if there is enough memory, there is better usage for fast tracks than pagefile.
OTOH, wildly swapping XP on 128-256 MB can benefit from fast pagefile.