>> > Adding another pool and copying all/some data over to it would only >> > a short term solution. >> >> I'll have to disagree. > > What is the point of a filesystem the can grow to such a huge size and > not have functionality built in to optimize data layout? Real world > implementations of filesystems that are intended to live for > years/decades need this functionality, don't they? > > Our mail system works well, only the backup doesn't perform well. > All the features of ZFS that make reads perform well (prefetch, ARC) > have little effect. > > We think backup is quite important. We do quite a few restores of months > old data. Snapshots help in the short term, but for longer term restores > we need to go to tape.
Your scalability problem may be in your backup solution. The problem is not how many Gb data you have but the number of files. It was a while since I worked with networker so things may have changed. If you are doing backups directly to tape you may have a buffering problem. By simply staging backups on disk we got at lot faster backups. Have you configured networker to do several simultaneous backups from your pool? You can do that by having several zfs on the same pool or tell networker to do backups one directory level down so that it thinks you have more file systems. And don't forget to play with the parallelism settings in networker. This made a huge difference for us on VxFS. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
