Florian Weimer <[EMAIL PROTECTED]> wrote: > * A. Pagaltzis: > > >> On Windows, perhaps. On most UNIX systems, this is very hard > >> to do and often not supported at all by the file system. > > > > Then again, Unix filesystems tend to be designed such > > that as long as there is sufficient free space on the > > device, fragmentation will remain insignificant. > > It's been this way on Windows for a couple of years, too. 8-) > > All this doesn't help that much if you've got a large file which grows > over time. For example, running "filefrag" on a Monotone database > stored on an ext3 file system before and after a small "pull" results > in: > > monotone.db: 9257 extents found, perfection would be 1 extent > monotone.db: 9403 extents found, perfection would be 1 extent > > This is with a page size of 4096 bytes. The default of 1024 is > probably even worse. >
See http://www.sqlite.org/cvstrac/chngview?cn=3255 The change above reduces the "reported" fragmentation considerably. But I'm not sure it will make any difference. Prior to the change above, the various pages of the file were all near each other on the disk, they just did not appear on the disk in sorted order. If you use "filefrag -v" you will see that many of the pages appear in reverse order. But they are still all contiguous on disk. So what you see above is not fragmentation in the usual sense of the word. The file is not scatter about all over the disk, requiring lots of head movement to access. The file is all in once place. It is just that the pages are out of order. The change in [3255] tends to keep the pages sorted on disk. But it is unclear if this will help performance any. The extra work that SQLite does to put the pages in order might actually make things go slower. I thought we would try [3255] for a while and see if it makes any difference. If you are able to run some tests both with and without patch [3255], I would be very interested in hearing the results of those tests. -- D. Richard Hipp <[EMAIL PROTECTED]>
