2010/12/8 taemun <tae...@gmail.com>: > Dedup? Taking a long time to boot after hard reboot after lookup? > > I'll bet that it hard locked whilst deleting some files or a dataset that > was dedup'd. After the delete is started, it spends *ages* cleaning up the > DDT (the table containing a list of dedup'd blocks). If you hard lock in the > middle of this clean up, then the DDT isn't valid, to anything. The next > mount attempt on that pool will do this operation for you. Which will take > an inordinate amount of time. My pool spent eight days (iirc) in limbo, > waiting for the DDT cleanup to finish. Once it did, it wrote out a shedload > of blocks and then everything was fine. This was for a zfs destroy of a > 900GB, 64KiB block dataset, over 2x 8-wide raidz vdevs.
Eight days is just... scary. Ok so basically it seems you can't have all the advantages of zfs at once. No more fsck, but if you have a deduplicated pool the kernel will still consider it as "unclean" if you have a crash or unclean shutdown? I am indeed nearly continously deleting older files because each day a mass of files gets written to the machine (and backups rotated). Is it in some way possible to do the cleanup in smaller increments so the amount of cleanup work to do when you (hard)reboot is smaller? > Unfortunately, raidz is of course slower for random reads than a set or > mirrors. The raidz/mirror hybrid allocator available in snv_148+ is somewhat > of a workaround for this, although I've not seen comprehensive figures for > the gain it gives > - http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6977913 -- Frank Van Damme No part of this copyright message may be reproduced, read or seen, dead or alive or by any means, including but not limited to telepathy without the benevolence of the author. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
