Hi all With several messages in here about troublesome zpools, would there be a good reason to be able to fsck a pool? As in, check the whole thing instead of having to boot into live CDs and whatnot? Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy at karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk.
----- Original Message -----> From: "Roy Sigurd Karlsbakk" <roy at karlsbakk.net> > To: "OpenSolaris ZFS discuss" <zfs-discuss at opensolaris.org> > Sent: Tuesday, 6 July, 2010 6:35:51 PM > Subject: [zfs-discuss] ZFS fsck? > Hi all > > With several messages in here about troublesome zpools, would there be > a good reason to be able to fsck a pool? As in, check the whole thing > instead of having to boot into live CDs and whatnot? > > Vennlige hilsener / Best regards > > royScrub? :)
On Tue, 6 Jul 2010, Roy Sigurd Karlsbakk wrote:> Hi all > > With several messages in here about troublesome zpools, would there be a > good reason to be able to fsck a pool? As in, check the whole thing > instead of having to boot into live CDs and whatnot?You can do this with "zpool scrub". It visits every allocated block and verifies that everything is correct. It''s not the same as fsck in that scrub can detect and repair problems with the pool still online and all datasets mounted, whereas fsck cannot handle mounted filesystems. If you really want to use it on an exported pool, you can use zdb, although it might take some time. Here''s an example on a small empty pool: # zpool create -f mypool raidz c4t1d0s0 c4t2d0s0 c4t3d0s0 c4t4d0s0 c4t5d0s0 # zpool list mypool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT mypool 484M 280K 484M 0% 1.00x ONLINE - # zpool export mypool # zdb -ebcc mypool Traversing all blocks to verify checksums and verify nothing leaked ... No leaks (block sum matches space maps exactly) bp count: 48 bp logical: 378368 avg: 7882 bp physical: 39424 avg: 821 compression: 9.60 bp allocated: 185344 avg: 3861 compression: 2.04 bp deduped: 0 ref>1: 0 deduplication: 1.00 SPA allocated: 185344 used: 0.04% #
> You can do this with "zpool scrub". It visits every allocated block > and > verifies that everything is correct. It''s not the same as fsck in that > scrub can detect and repair problems with the pool still online and > all > datasets mounted, whereas fsck cannot handle mounted filesystems. > > If you really want to use it on an exported pool, you can use zdb, > although it might take some time. Here''s an example on a small empty > pool: > > # zpool create -f mypool raidz c4t1d0s0 c4t2d0s0 c4t3d0s0 c4t4d0s0 > c4t5d0s0 > # zpool list mypool > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > mypool 484M 280K 484M 0% 1.00x ONLINE - > # zpool export mypool > # zdb -ebcc mypool... what I''m saying is that there are several posts in here where the only solution is to boot onto a live cd and then do an import, due to metadata corruption. This should be doable from the installed system Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy at karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk.
On Tue, 6 Jul 2010, Roy Sigurd Karlsbakk wrote:> what I''m saying is that there are several posts in here where the only > solution is to boot onto a live cd and then do an import, due to > metadata corruption. This should be doable from the installed systemAh, I understand now. A couple of things worth noting: - if the root filesystem in a boot pool cannot be mounted, it''s problematic to access the tools necessary to repair it. So going to a livecd (or a network boot for that matter) is the best way forward. - if the tools available to failsafe are insufficient to repair a pool, then booting off a livecd/network is the only way forward. It is also worth pointing out here that the 134a build has the pool recovery code built-in. The "-F" option to zpool import only became available after build 128 or 129.