Yes, my mistake was probably that I have included data deduplication to see how it works, but not turned it off at the right time . In this case, the machine memory of 4 GB .... async_destroy - too enabled. That is the conclusion I have deduplication disabled . How to import a pool of read-only ? Thank you for your response . zpool get all zroot NAME?? PROPERTY?????????????????????? VALUE????????????????????????? SOURCE zroot? size?????????????????????????? 230G?????????????????????????? - zroot? capacity?????????????????????? 24%??????????????????????????? - zroot? altroot??????????????????????? -????????????????????????????? default zroot? health???????????????????????? ONLINE???????????????????????? - zroot? guid?????????????????????????? 1229884058434432944??????????? default zroot? version??????????????????????? -????????????????????????????? default zroot? bootfs???????????????????????? zroot????????????????????????? local zroot? delegation???????????????????? on???????????????????????????? default zroot? autoreplace??????????????????? on???????????????????????????? local zroot? cachefile????????????????????? -????????????????????????????? default zroot? failmode?????????????????????? wait?????????????????????????? default zroot? listsnapshots????????????????? on???????????????????????????? local zroot? autoexpand???????????????????? off??????????????????????????? default zroot? dedupditto???????????????????? 0????????????????????????????? default zroot? dedupratio???????????????????? 1.02x????????????????????????? - zroot? free?????????????????????????? 174G?????????????????????????? - zroot? allocated????????????????????? 56.1G????????????????????????? - zroot? readonly?????????????????????? off??????????????????????????? - zroot? comment??????????????????????? ZFS ?????????????????????????? local zroot? expandsize???????????????????? 0????????????????????????????? - zroot? freeing??????????????????????? 0????????????????????????????? default zroot? feature at async_destroy????????? enabled??????????????????????? local zroot? feature at empty_bpobj??????????? active???????????????????????? local zroot? feature at lz4_compress?????????? active???????????????????????? local zroot? feature at multi_vdev_crash_dump? enabled??????????????????????? local zroot? feature at spacemap_histogram???? active???????????????????????? local zroot? feature at enabled_txg??????????? active???????????????????????? local zroot? feature at hole_birth???????????? active???????????????????????? local zroot? feature at extensible_dataset???? enabled??????????????????????? local zroot? feature at bookmarks????????????? enabled??????????????????????? local zroot? feature at filesystem_limits????? enabled??????????????????????? local ???????????, 30 ????? 2015, 0:36 -07:00 ?? Xin Li <delphij at delphij.net>:>-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA512 > > > >On 3/27/15 05:26, armonia wrote: >> After importing I press ctrl + t and here's the conclusion: >> >> load: 0.20 cmd: zpool 725 [tx->tx_sync_done_cv] 32.50r 0.00y 5.59s >> 0% 6432k > >Have you ever enabled e.g. dedup on certain dataset(s) and have a lot >of files, and the pool don't have 'async destroy' feature enabled? In >that case the fastest way to recover, if this took too long, would >probably import the pool read-only and copy data to another pool. > >On -CURRENT you can use dtrace -qn 'zfs-dbgmsg{printf("%s\n", >stringof(arg0))}' to see more verbose information, they are not always >helpful but will give you better idea on what is going on under the hood >. > >Cheers, >-----BEGIN PGP SIGNATURE----- > >iQIcBAEBCgAGBQJVGP0IAAoJEJW2GBstM+nsjRUP/11uzAQjAhQdOKTDMYt9gbTt >DsMn1C5x3X+btMuMyJ6JfxiOhm1qxolDEsjilodpj+i7m09a42N1GZrqEKBIY4PP >wvVwHHGuG1+zvpcQYfyWz50lKOgSIeLY3CUkyRRLHu3XsGrhj6uVEBjJRqLzRFof >oCTlAPeXFkZgs5wkufwJ9kx5JJT4UvZKyBbj3CNL7xMGmEIKffIMZWQv3SzIROdU >3QLjKSxTX969l6bNPEG/Fr262SZvXq9wPF2hbXs+AgLeDduz+ILhOMF1Za9+PTu+ >U5zJM5MUEOimacAys0ldQ5kVarufFySCv1VXvmIyUPPsVu+WuBAWE7lC1c8tdNnh >vawMSfA2z5GtowxcpRVkl0CuVdO9AHZ2cHQzqrVh+rC/3HEdpCiUYakvoU3g1LhT >9Yo1s6dDUQcl6cfObDw5QU1eNc5dnCwENef5UnraH/GYbV4u8j4ClBPD7jw7zdlo >jgGVMcXORJEztYW3LCQNUU0phP0c3jNm9x84Do4AhLPMTPfxPrXiHJy/BtSrDw4B >BZlvqDRhaaOlTU/RPoAIdzFm1PztGLG2r5zrPR/ZKB3UquDctWSNz84jvgN3OK0d >XyTsJsAH3lRLO5RNIt/Km4z86vnmL0WZdiY919XsBWlVbh1db+qKHs/KeSpaJ1Fd >wqeqhWwU8l5yGKik19du >=Bm6L >-----END PGP SIGNATURE----- >_______________________________________________ >freebsd-stable at freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to " freebsd-stable-unsubscribe at freebsd.org "--
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/30/15 01:32, armonia wrote:> Yes, my mistake was probably that I have included data > deduplication to see how it works, but not turned it off at the > right time. In this case, the machine memory of 4 GB .... > > async_destroy - too enabled. > > That is the conclusion I have deduplication disabled.Hrm, usually async_destroy should be enough to protect against this situation. Can you try if setting the sysctl variable vfs.zfs.free_max_blocks to a limited number, like, 100,000, would make the pool import properly? You may have run out of memory because of too much data being free'ed in one transaction group? (I would recommend doing this after importing the pool read-only and copy your data off, though).> How to import a pool of read-only?zpool import -o readonly poolname.> Thank you for your response. > > zpool get all zroot NAME PROPERTY VALUE > SOURCE zroot size 230G > - zroot capacity 24% > - zroot altroot - > default zroot health ONLINE > - zroot guid 1229884058434432944 > default zroot version - > default zroot bootfs zroot > local zroot delegation on > default zroot autoreplace on > local zroot cachefile - > default zroot failmode wait > default zroot listsnapshots on > local zroot autoexpand off > default zroot dedupditto 0 > default zroot dedupratio 1.02x > - zroot free 174G > - zroot allocated 56.1G > - zroot readonly off > - zroot comment ZFS > local zroot expandsize 0 > - zroot freeing 0 > default zroot feature at async_destroy enabled > local zroot feature at empty_bpobj active > local zroot feature at lz4_compress active > local zroot feature at multi_vdev_crash_dump enabled > local zroot feature at spacemap_histogram active > local zroot feature at enabled_txg active > local zroot feature at hole_birth active > local zroot feature at extensible_dataset enabled > local zroot feature at bookmarks enabled > local zroot feature at filesystem_limits enabled > local > > > ???????????, 30 ????? 2015, 0:36 -07:00 ?? Xin Li > <delphij at delphij.net>: > > > > On 3/27/15 05:26, armonia wrote: >> After importing I press ctrl + t and here's the conclusion: > >> load: 0.20 cmd: zpool 725 [tx->tx_sync_done_cv] 32.50r 0.00y >> 5.59s 0% 6432k > > Have you ever enabled e.g. dedup on certain dataset(s) and have a > lot of files, and the pool don't have 'async destroy' feature > enabled? In that case the fastest way to recover, if this took too > long, would probably import the pool read-only and copy data to > another pool. > > On -CURRENT you can use dtrace -qn 'zfs-dbgmsg{printf("%s\n", > stringof(arg0))}' to see more verbose information, they are not > always helpful but will give you better idea on what is going on > under the hood . > > Cheers, _______________________________________________ > freebsd-stable at freebsd.org > </compose?To=freebsd%2dstable at freebsd.org> mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable To > unsubscribe, send any mail to > "freebsd-stable-unsubscribe at freebsd.org > </compose?To=freebsd%2dstable%2dunsubscribe at freebsd.org>" > > > > --- -- Xin LI <delphij at delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVGZPKAAoJEJW2GBstM+nsPIAP/2aX5MItnX/LiLII+xKp/Hnx 9TZWUdpEqwOpIWovjiF7N+Vp9Uz8RCCHl5yzMbd5p/cvaP6h7oQZiJYzBDLVRx61 Rk3Uz7/SyycWPXlD6lhNYPZ9QrptgO6hhX5y4YHxOlibhe7NLCmZYNxBqNsqR0HW FoseCRP2+ima4Qu5P4dVKDCnKwMdifP7qvrbOZcyYWIVThVBH14Rp7w9zfiiAN6v AYSY9JLMYQGILfexORo/LG+kYI3gT2CIhYVNpfCsQLo5GNOucAZNYM5oO4aCt/BQ 2DIzhp58F1z7JYUwZVJ0p7GSjuZ2peWqYYyGMqFkBU0cydskGj+wGwu154sx6Vyg xAgzqH/jG95DqkC6yDRoy/bvJ0zam2z3N9jR+XRqgVsuwYbEG7dQp6TBByN5PWp+ UaRexsvknjNJA6Otqei5qQ5fcXfhaalTD+/3XB3eqExJa6sbONZ6qJdLeiDYe+3V wNRnuDQwatLCkLhQoFbXIdXQJ16Da4evmMrHd+YsKrytx2F/wMoNZru7Ilv6X+5L LhuGg26Kh2ohZQGvn4cWCus63wRWweEjpTpD4Ng2Ok+qIEgquC9kcveV1TSwxWi1 ZusD5hYqJXO2rA6iB2MyQqZi6t4fBK00CG7SkAegrNaKnH2e245s7qwsg6huKKUA yMt5wuj4GXbRg9yjWs0j =m5xz -----END PGP SIGNATURE-----