Re: [osol-discuss] fsck seems to have a few new features in build 26
Jonathan Adams schrieb: On Tue, Nov 15, 2005 at 08:06:06PM -0500, Dennis Clarke wrote: Hold on .. do you mean from the ok prompt ? ok boot -m milestone=none as opposed to ok boot -sv hmmm fascinating ... let me try that right now. Yes; it's a completely minimal boot, with nothing but init(1M), svc.startd(1M), svc.configd(1M), and sulogin(1M) running. Finally we have an official replacement for the undocumented boot -b flag in earlier Solaris releases. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] fsck seems to have a few new features in build 26
I just saw this : fsck -F ufs -Y /dev/rdsk/c0t0** /dev/dsk/c0t0d0s0 ** Currently Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups FILESYSTEM MAY STILL BE INCONSISTENT. 5331 files, 134218 used, 356643 free (539 frags, 44513 blocks, 0.1% fragmentation) * FILE SYSTEM IS BAD * * PLEASE RERUN FSCK * I didn't see those new 3a and 3b stages before. That is interesting. I did rerun fsck again and I get the same message over and over. I suspect that something else must be happening here. I may boot with the cdrom just to verify. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On Tue 15 Nov 2005 at 03:50PM, Dennis Clarke wrote: I just saw this : fsck -F ufs -Y /dev/rdsk/c0t0** /dev/dsk/c0t0d0s0 ** Currently Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups FILESYSTEM MAY STILL BE INCONSISTENT. 5331 files, 134218 used, 356643 free (539 frags, 44513 blocks, 0.1% fragmentation) * FILE SYSTEM IS BAD * * PLEASE RERUN FSCK * I didn't see those new 3a and 3b stages before. That is interesting. I did rerun fsck again and I get the same message over and over. I suspect that something else must be happening here. I may boot with the cdrom just to verify. Yes, there has been work done on fsck recently, in snv_22: 1260290 RFE: fsck error: UNKNOWN FILE TYPE describes multiple error conditions 4836779 fsck requires multiple runs to clear up DUP or BAD blocks 4845221 ufs/fsck can't handle filesystem name argument 4857410 ufs_sync_indir() walks off the end of the i_ib array 4872089 fsck almost always reports FREE BLK COUNT(S) WRONG IN SUPERBLK 4890510 fsck can't properly recover the filesystem 5086715 ufs fsck has memory leaks 6175186 fsck should not need to be run multiple times 6208131 fsck needs to be able to recover filesystem problems (nbfree,ndir,nifree ,nffree suspect) 6312941 PSARC 2005/044 UFS fsck rerun messaging 6312946 PSARC 2005/045 UFS fsck verbose option 6312949 PSARC 2005/051 UFS fsck automated search for a backup superblocks 6312954 PSARC 2005/043 UFS newfs/mkfs superblock calculation options So, it's possible you've found a bug or just an existing problem in fsck? I've BCC'd the author of these changes; hopefully he'll also respond. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On 11/15/05, Dan Price [EMAIL PROTECTED] wrote: On Tue 15 Nov 2005 at 03:50PM, Dennis Clarke wrote: I just saw this : fsck -F ufs -Y /dev/rdsk/c0t0** /dev/dsk/c0t0d0s0 snippage I did rerun fsck again and I get the same message over and over. I suspect that something else must be happening here. I may boot with the cdrom just to verify. Yes, there has been work done on fsck recently, in snv_22: 1260290 RFE: fsck error: UNKNOWN FILE TYPE describes multiple error conditions 4836779 fsck requires multiple runs to clear up DUP or BAD blocks 4845221 ufs/fsck can't handle filesystem name argument 4857410 ufs_sync_indir() walks off the end of the i_ib array 4872089 fsck almost always reports FREE BLK COUNT(S) WRONG IN SUPERBLK 4890510 fsck can't properly recover the filesystem 5086715 ufs fsck has memory leaks 6175186 fsck should not need to be run multiple times 6208131 fsck needs to be able to recover filesystem problems (nbfree,ndir,nifree ,nffree suspect) 6312941 PSARC 2005/044 UFS fsck rerun messaging 6312946 PSARC 2005/045 UFS fsck verbose option 6312949 PSARC 2005/051 UFS fsck automated search for a backup superblocks 6312954 PSARC 2005/043 UFS newfs/mkfs superblock calculation options whoa .. that is a lot of work done. So, it's possible you've found a bug or just an existing problem in fsck? It could just be my boot drive dying also :-) I've BCC'd the author of these changes; hopefully he'll also respond. I don't want to cause work for anyone. Let me run a surface scan of the disk with analyze and see if the disk is shot. If all is well then I will restore from ufsdumps and see what fsck says again. If we still get complaints then perhaps there is a problem. This is on UltraSparc by the way although I expect the code to be the same regardless. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On Tue 15 Nov 2005 at 04:11PM, Dennis Clarke wrote: On 11/15/05, Dan Price [EMAIL PROTECTED] wrote: On Tue 15 Nov 2005 at 03:50PM, Dennis Clarke wrote: I just saw this : fsck -F ufs -Y /dev/rdsk/c0t0** /dev/dsk/c0t0d0s0 snippage I did rerun fsck again and I get the same message over and over. I suspect that something else must be happening here. I may boot with the cdrom just to verify. Yes, there has been work done on fsck recently, in snv_22: 1260290 RFE: fsck error: UNKNOWN FILE TYPE describes multiple error conditions 4836779 fsck requires multiple runs to clear up DUP or BAD blocks 4845221 ufs/fsck can't handle filesystem name argument 4857410 ufs_sync_indir() walks off the end of the i_ib array 4872089 fsck almost always reports FREE BLK COUNT(S) WRONG IN SUPERBLK 4890510 fsck can't properly recover the filesystem 5086715 ufs fsck has memory leaks 6175186 fsck should not need to be run multiple times 6208131 fsck needs to be able to recover filesystem problems (nbfree,ndir,nifree ,nffree suspect) 6312941 PSARC 2005/044 UFS fsck rerun messaging 6312946 PSARC 2005/045 UFS fsck verbose option 6312949 PSARC 2005/051 UFS fsck automated search for a backup superblocks 6312954 PSARC 2005/043 UFS newfs/mkfs superblock calculation options whoa .. that is a lot of work done. Yeah. A nice feature of the source browser is that you can now identify exactly what that change was: http://cvs.opensolaris.org/source/diff/on/usr/src/cmd/fs.d/ufs/fsck/main.c?r2=1.50r1=1.48 And you can search in the history box of the source browser for any of the bug IDs or case IDs above, and find the associated changes. Thank you Chandan!! -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On 11/15/05, Sean Wilcox [EMAIL PROTECTED] wrote: This is because the filesystem is mounted read/write, and there is no way for fsck to 100% guarentee that the fs is sane after it has been run, especially with the -Y option, on a fs that is mounted read/write due to possible modification that might have tripped up fsck's ability to track things correctly. The Statement that the FILE SYSTEM IS BAD is probably a little too harsh but the FS INCONSISTENT statement could be true. Well, the ability to boot so single user mode and then run fsck on the current root slice seems to be something that I have done for a long long time. I think I may have to consider that one must now boot from some other media in order to be assured of fs sanity. In either case, its too late, I have booted via CDROM ( Solaris Express build 25 ) and am presently ufsdump'ing everything and then I will run a full surface scan of the disk sector by sector. If I am doing nothing but wasting my time .. well .. its too late now. At any rate, I will be able to re-create the critical filesystems with my own specs ( via mkfs_ufs ) and then ufsrestore from the dumps. There is a little voice in my head that whispers zfs will make this all a distant memory but what do I know. I have yet to see the specs for zfs. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
This is because the filesystem is mounted read/write, and there is no way for fsck to 100% guarentee that the fs is sane after it has been run, especially with the -Y option, on a fs that is mounted read/write due to possible modification that might have tripped up fsck's ability to track things correctly. The Statement that the FILE SYSTEM IS BAD is probably a little too harsh but the FS INCONSISTENT statement could be true. Dan Price wrote: On Tue 15 Nov 2005 at 03:50PM, Dennis Clarke wrote: I just saw this : fsck -F ufs -Y /dev/rdsk/c0t0** /dev/dsk/c0t0d0s0 ** Currently Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups FILESYSTEM MAY STILL BE INCONSISTENT. 5331 files, 134218 used, 356643 free (539 frags, 44513 blocks, 0.1% fragmentation) * FILE SYSTEM IS BAD * * PLEASE RERUN FSCK * I didn't see those new 3a and 3b stages before. That is interesting. I did rerun fsck again and I get the same message over and over. I suspect that something else must be happening here. I may boot with the cdrom just to verify. -- Sean Wilcox OP/N1 RPE - Data Direct: (303) 272-9711 x79711 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On Tue, Nov 15, 2005 at 04:49:31PM -0500, Dennis Clarke wrote: On 11/15/05, Sean Wilcox [EMAIL PROTECTED] wrote: This is because the filesystem is mounted read/write, and there is no way for fsck to 100% guarentee that the fs is sane after it has been run, especially with the -Y option, on a fs that is mounted read/write due to possible modification that might have tripped up fsck's ability to track things correctly. The Statement that the FILE SYSTEM IS BAD is probably a little too harsh but the FS INCONSISTENT statement could be true. Well, the ability to boot so single user mode and then run fsck on the current root slice seems to be something that I have done for a long long time. I think I may have to consider that one must now boot from some other media in order to be assured of fs sanity. You can always boot with '-m milestone=none', and run fsck from that environment; the root filesystem will be mounted read-only. In single-user mode, you might be able to re-mount the root filesystem read-only (mount -o ro,remount /), but I'm not sure that's supported. You could try to write-lock it using lockfs -fw /, but I'm not sure that's well-advised. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On 11/15/05, Jonathan Adams [EMAIL PROTECTED] wrote: On Tue, Nov 15, 2005 at 04:49:31PM -0500, Dennis Clarke wrote: On 11/15/05, Sean Wilcox [EMAIL PROTECTED] wrote: This is because the filesystem is mounted read/write, and there is no way for fsck to 100% guarentee that the fs is sane after it has been run, especially with the -Y option, on a fs that is mounted read/write due to possible modification that might have tripped up fsck's ability to track things correctly. The Statement that the FILE SYSTEM IS BAD is probably a little too harsh but the FS INCONSISTENT statement could be true. Well, the ability to boot so single user mode and then run fsck on the current root slice seems to be something that I have done for a long long time. I think I may have to consider that one must now boot from some other media in order to be assured of fs sanity. You can always boot with '-m milestone=none', and run fsck from that environment; the root filesystem will be mounted read-only. Hold on .. do you mean from the ok prompt ? ok boot -m milestone=none as opposed to ok boot -sv hmmm fascinating ... let me try that right now. In single-user mode, you might be able to re-mount the root filesystem read-only (mount -o ro,remount /), but I'm not sure that's supported. You could try to write-lock it using lockfs -fw /, but I'm not sure that's well-advised. Well thank you for the advice. At this juncture it looks like my disk is fine : analyze set Analyze entire disk[yes]? Loop continuously[no]? Enter number of passes[2]: Repair defective blocks[yes]? Stop after first error[no]? Use random bit patterns[no]? yes Enter number of blocks per transfer[126, 0/0/126]: Verify media after formatting[yes]? Enable extended messages[no]? yes Restore defect list[yes]? Restore disk label[yes]? analyze compare Ready to analyze (will corrupt data). This takes a long time, but is interruptable with CTRL-C. Continue? yes pass 0 - pattern = 0x657eb725 4923/26/7 pass 1 - pattern = 0xd72a0c96 4923/26/7 Total of 0 defective blocks repaired. analyze however my methods need to be modernized a tad. I will now need to restore from my dump files and then try that boot -m milestone=none Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On Tue, Nov 15, 2005 at 08:06:06PM -0500, Dennis Clarke wrote: On 11/15/05, Jonathan Adams [EMAIL PROTECTED] wrote: On Tue, Nov 15, 2005 at 04:49:31PM -0500, Dennis Clarke wrote: On 11/15/05, Sean Wilcox [EMAIL PROTECTED] wrote: This is because the filesystem is mounted read/write, and there is no way for fsck to 100% guarentee that the fs is sane after it has been run, especially with the -Y option, on a fs that is mounted read/write due to possible modification that might have tripped up fsck's ability to track things correctly. The Statement that the FILE SYSTEM IS BAD is probably a little too harsh but the FS INCONSISTENT statement could be true. Well, the ability to boot so single user mode and then run fsck on the current root slice seems to be something that I have done for a long long time. I think I may have to consider that one must now boot from some other media in order to be assured of fs sanity. You can always boot with '-m milestone=none', and run fsck from that environment; the root filesystem will be mounted read-only. Hold on .. do you mean from the ok prompt ? ok boot -m milestone=none as opposed to ok boot -sv hmmm fascinating ... let me try that right now. Yes; it's a completely minimal boot, with nothing but init(1M), svc.startd(1M), svc.configd(1M), and sulogin(1M) running. When you are ready to bring the system up, you can do: # svcadm milestone all and exit the shell (or keep the shell, and watch the system come up by running svcs(1) over and over again). The console login prompt won't appear until you exit your shell. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
On 11/15/05, Jonathan Adams [EMAIL PROTECTED] wrote: On Tue, Nov 15, 2005 at 08:06:06PM -0500, Dennis Clarke wrote: On 11/15/05, Jonathan Adams [EMAIL PROTECTED] wrote: On Tue, Nov 15, 2005 at 04:49:31PM -0500, Dennis Clarke wrote: On 11/15/05, Sean Wilcox [EMAIL PROTECTED] wrote: The Statement that the FILE SYSTEM IS BAD is probably a little too harsh but the FS INCONSISTENT statement could be true. You can always boot with '-m milestone=none', and run fsck from that environment; the root filesystem will be mounted read-only. Hold on .. do you mean from the ok prompt ? ok boot -m milestone=none as opposed to ok boot -sv hmmm fascinating ... let me try that right now. Yes; it's a completely minimal boot, with nothing but init(1M), svc.startd(1M), svc.configd(1M), and sulogin(1M) running. When you are ready to bring the system up, you can do: # svcadm milestone all hmmm cool. I really have to take a pile of my old tools in sysadmin life and toss them over my shoulder and check out all these new functions and features. and exit the shell (or keep the shell, and watch the system come up by running svcs(1) over and over again). The console login prompt won't appear until you exit your shell. Okay .. I'm going to try that in a very experimental kind of way. Also .. I just noticed something else. I need to recreate my filesystems after running analyze and thus when I went to newfs my /dev/rdsk/c0t0d0s0 I noticed a new option or two that was not there before : # newfs -? usage: newfs [ -v ] [ mkfs-options ] raw-special-device where mkfs-options are: -N do not create file system, just print out parameters -T configure file system for eventual growth to over a terabyte -s file system size (sectors) -b block size -f frag size -t tracks/cylinder -c cylinders/group -m minimum free space % -o optimization preference (`space' or `time') -r revolutions/minute -i number of bytes per inode -a number of alternates per cylinder -C maxcontig -d rotational delay -n number of rotational positions -S print a textual version of the calculated superblock to stdout -B dump a binary version of the calculated superblock to stdout Hmmm a -S option and a -B optiion for dumping the superblock data ? Let me give that a whirl : # newfs -s 1048572 -b 8192 -f 1024 -m 10 -i 2048 -S /dev/rdsk/c0t0d0s0 newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y 0x0 sblock.fs_link 0x0 sblock.fs_rolled 0x10 sblock.fs_sblkno 0x18 sblock.fs_cblkno . . . 0x0 sblock.fs_sparecon[49] 0x0 sblock.fs_sparecon[50] 0x0 sblock.fs_version 0x0 sblock.fs_logbno 0x0 sblock.fs_reclaim 0x0 sblock.fs_sparecon2 0x38ac117c sblock.fs_state 0xffbffbc0 sblock.fs_qbmask 0xffbffbb8 sblock.fs_qfmask 0x1 sblock.fs_postblformat 0x8 sblock.fs_nrpos 0x35c sblock.fs_postbloff 0x560 sblock.fs_rotbloff 0x11954 sblock.fs_magic fsirand: Not a file system (bad magic number in superblock) /usr/sbin/fsirand /dev/rdsk/c0t0d0s0: failed, status = 256 # That seemed to generate an error of some sort there. I'll try the old fashioned method : # newfs -s 1048572 -b 8192 -f 1024 -m 10 -i 2048 /dev/rdsk/c0t0d0s0 newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y /dev/rdsk/c0t0d0s0: 1048572 sectors in 292 cylinders of 27 tracks, 133 sectors 512.0MB in 19 cyl groups (16 c/g, 28.05MB/g, 13504 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232, 460832, 518432, 576032, 633632, 691232, 748832, 806432, 864032, 921632, 979232, 1036832, # yep .. okay. Once I have my filesystems restored I will then experiment with these new boot options! Dennis ps: I love experimenting with new things like this. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
