... > With regards sharing the disk resources with other > programs, obviously it's down to the individual > admins how they would configure this,
Only if they have an unconstrained budget. but I would > suggest that if you have a database with heavy enough > requirements to be suffering noticable read > performance issues due to fragmentation, then that > database really should have it's own dedicated drives > and shouldn't be competing with other programs. You're not looking at it from a whole-system viewpoint (which if you're accustomed to having your own dedicated storage devices is understandable). Even if your database performance is acceptable, if it's performing 50x as many disk seeks as it would otherwise need to when scanning a table that's affecting the performance of *other* applications. > > Also, I'm not saying defrag is bad (it may be the > better solution here), just that if you're looking at > performance in this kind of depth, you're probably > experienced enough to have created the database in a > contiguous chunk in the first place :-) As I noted, ZFS may not allow you to ensure that and in any event if the database grows that contiguity may need to be reestablished. You could grow the db in separate files, each of which was preallocated in full (though again ZFS may not allow you to ensure that each is created contiguously on disk), but while databases may include such facilities as a matter of course it would still (all other things being equal) be easier to manage everything if it could just extend a single existing file (or one file per table, if they needed to be kept separate) as it needed additional space. > > I do agree that doing these writes now sounds like a > lot of work. I'm guessing that needing two full-path > updates to achieve this means you're talking about a > much greater write penalty. Not all that much. Each full-path update is still only a single write request to the disk, since all the path blocks (again, possibly excepting the superblock) are batch-written together, thus mostly increasing only streaming bandwidth consumption. ... > It may be that ZFS is not a good fit for this kind of > use, and that if you're really concerned about this > kind of performance you should be looking at other > file systems. I suspect that while it may not be a great fit now with relatively minor changes it could be at least an acceptable one. - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
