> > .. however ... a lot of snaps still have a impact > on system performance. After the import of the 10000 > snaps volume, I saw "devfsadm" eating up all CPU: > > If you are snapshotting ZFS volumes, then each will > create an entry in the > device tree. In other words, if these were file > systems instead of volumes, you > would not see devfsadm so busy.
Ok, nice to know that. For our use case we are focused on zvols (comstar iSCSi to virtualized hosts). And still it works fine for a reasonable number of zvols with a nice backup/snapshot cycle (~ 12 (5min) + 24 (1h) +7 (daily) + 4 (weekly) + 12 (monthly) + 1 for each year -> ~ 60 Snaps for each zvol). > > .. another strange issue: > > r...@osol_dev130:/dev/zvol/dsk/ssd# ls -al > > > > load averages: 1.16, 2.17, 1.50; > up 0+00:22:07 18:54:00 > : 97 sleeping, 2 on cpu > > CPU states: 49.1% idle, 0.1% user, 50.8% kernel, > I don't see the issue, could you elaborate? How ( I know how to "truss", but not not so familiar with debugging at the kernel level :) ? > > .. so having a 10000 snaps of a single zvol is not > nice :) > > AIUI, devfsadm creates a database. Could you try the > last experiment again, Will try, but have no access to test equipment right now. Thanks for the feedback. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
