Re: fsck problem
07.01.2013 03:15, Kirk McKusick пишет: Date: Wed, 02 Jan 2013 00:46:53 +0400 From: Alex Keda To: curr...@freebsd.org Subject: fsck problem so, whats reason for use SUJ? SUJ is used to speed up the fsck process. If you have had hard disk errors then it is not able to recover and you need to run fsck in the old full-fsck way. It is not necessary to disable the journal. If fsck runs and fails it marks the journal as failed so when you rerun fsck it will run in the old full-fsck mode. Note that running `fsck -y' is not recommended as that says make this filesystem clean no matter what. So while you will end up with a clean filesystem, it may be empty if you had a bad block in the root directory. Instead you should run fsck and read and think about the questions rather than just blindly answering them all yes. it's HDD not have bad blocks - it's hardware RAID10 I run fsck -y more than 3 time, before disable journal. it's can't fix error, with enabled journal and, I see it's error not first time. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
fsck problem
Starting file system checks: /dev/label/rootFS: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/label/rootFS: clean, 11916812 free (74068 frags, 1480343 blocks, 0.5% fragmentation) ** SU+J Recovering /dev/label/homeFS ** Reading 33554432 byte journal from inode 12. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. fsck_ufs: Directory 1136967 name not found THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/label/homeFS (/home) Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Jan 2 04:35:11 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: # g\^H\^[[Kfsck -y .home fsck: cannot open `/dev/.home': No such file or directory # fsck -y .home\^H\^H\^H\^H\^Hhome\^[[K\^H\^H\^H\^H/home\^H\^H\^H\^H twa0: INFO: (0x04: 0x0029): Verify started: unit=0, subunit=1 twa0: INFO: (0x04: 0x0029): Verify started: unit=0, subunit=0 ** /dev/label/homeFS USE JOURNAL? yes ** SU+J Recovering /dev/label/homeFS ** Reading 33554432 byte journal from inode 12. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. fsck_ufs: Directory 1136967 name not found # tunefs -j disable .\^H\^[[K/home Clearing journal flags from inode 12 tunefs: soft updates journaling cleared but soft updates still set. tunefs: remove .sujournal to reclaim space # tunefs -j disable /home\^[[23D\^[[10Pfsck -y\^[[6C ** /dev/label/homeFS ** Last Mounted on /home ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=48071192 OWNER=www MODE=100600 SIZE=5472256 MTIME=Jan 1 23:59 2013 CLEAR? yes UNREF FILE I=48071193 OWNER=www MODE=100600 SIZE=3538944 MTIME=Jan 2 00:01 2013 CLEAR? yes UNREF FILE I=53478932 OWNER=h40708 MODE=100644 SIZE=81 MTIME=Dec 29 00:24 2012 CLEAR? yes UNREF FILE I=53478934 OWNER=h40708 MODE=100644 SIZE=67 MTIME=Dec 27 17:24 2012 CLEAR? yes UNREF FILE I=53478935 OWNER=h40708 MODE=100644 SIZE=71 MTIME=Dec 28 12:34 2012 CLEAR? yes UNREF FILE I=53478947 OWNER=h40708 MODE=100644 SIZE=88 MTIME=Jan 1 18:10 2013 CLEAR? yes UNREF FILE I=53478953 OWNER=h40708 MODE=100644 SIZE=70 MTIME=Dec 28 00:42 2012 CLEAR? yes UNREF FILE I=53478954 OWNER=h40708 MODE=100644 SIZE=66 MTIME=Dec 31 08:20 2012 CLEAR? yes UNREF FILE I=53478956 OWNER=h40708 MODE=100644 SIZE=72 MTIME=Dec 28 00:48 2012 CLEAR? yes ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 2587656 files, 12137676 used, 212163011 free (637755 frags, 26440657 blocks, 0.3% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * # # # # # ^DSetting hostuuid: 564d258e-1ef7-b7a3-bde0-b6bca10c3382. Setting hostid: 0x88403a99. Entropy harvesting: interrupts ethernet point_to_point kickstart. Fast boot: skipping disk checks. Mounting local file systems:. === so, whats rason for use SUJ? about system: srv0$ uname -a FreeBSD srv0.host-food.ru 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Wed Dec 5 04:05:50 MSK 2012 t...@srv0.host-food.ru:/usr/obj/usr/src/sys/HOST-FOOD amd64 srv0$ mount /dev/label/rootFS on / (ufs, local) devfs on /dev (devfs, local, multilabel) /dev/label/homeFS on /home (ufs, local, noatime, nosuid, with quotas, soft-updates) linprocfs on /proc (linprocfs, local) tmpfs on /tmp (tmpfs, local, noexec, nosuid) devfs on /var/named/dev (devfs, local, multilabel) srv0$ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/label/rootFS 59G 13G 40G25%/ devfs1.0k1.0k 0B 100%/dev /dev/label/homeFS855G 46G740G 6%/home linprocfs4.0k4.0k 0B 100%/proc tmpfs 14G4.0k 14G 0%/tmp devfs1.0k1.0k 0B 100%/var/named/dev srv0$ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J and fsck problem ?
Hi, I think you've included enough info. I don't know if fsck is supposed to work that way with journalling but if not, it'd be nice to get that documented. I'd also like to see that "timestamp mismatch" print out the timestamps so we can see what's going on. Eg, if your clock is somehow skewing. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J and fsck problem ?
Adrian Chadd freebsd.org> writes: > > Please file a PR and put as much debugging output as you can. > ... Because this is a case of clean shutdown and oing on purpose to single user mode to see how these hings behave, I assume I can go and try again and collect similar info. But, is there any debugging method I as a user can utilize to collect specific info that could aid devs ? jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J and fsck problem ?
Please file a PR and put as much debugging output as you can. I haven't had it fail for me on any of my test machines that panic _very frequently_. But I only hvae a single disk with minimal IO, I haven't had it crash doing lots of ongoing server style iO. adrian On 11 March 2012 00:19, Alex Keda wrote: > On 10.03.2012 14:01, jb wrote: >> >> Hi, >> >> FB9.0-RELEASE; no updates or recompilation. >> >> In multi-user mode: >> $ mount >> /dev/ada0s2a on / (ufs, local, journaled soft-updates) >> The fs was in normal state (no known problem, clean shutdown), >> >> Booted by choice in single-user mode. >> >> # mount >> /dev/ada0s2a on / (ufs, local, read-only) >> >> # fsck -F >> ** /dev/ada0s2a >> >> USE JOURNAL? [yn] y >> >> ** SU+J recovering /dev/ada0s2a >> ** Reading 33554432 byte journal from inode 4. >> >> RECOVER? [yn] y >> >> ** ... >> ** Processing journal entries. >> >> WRITE CHANGES? [yn] y >> >> ** 208 journal records in 13312 bytes for 50% utilization >> ** Freed 0 inodes (0 dirs) 6 blocks, and 0 frags. >> >> * FILE SYSTEM MARKED CLEAN >> >> # fsck -F >> ** /dev/ada0s2a >> >> USE JOURNAL? [yn] n >> >> ** Skipping journal, falling through to full fsck >> >> ** Last Mounted on / >> ** Root file system >> ** Phase 1 - Check Blocks and Sizes >> INCORRECT BLOCK COUNT I=114700 (8 should be 0) >> CORRECT? [yn] n >> >> INCORRECT BLOCK COUNT I=196081 (32 should be 8) >> CORRECT? [yn] n >> >> INCORRECT BLOCK COUNT I=474381 (32 should be 8) >> CORRECT? [yn] n >> >> ** Phase 2 - Check Pathnames >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> ** Phase 5 - Check Cyl groups >> FREE BLOCK COUNTS(S) WRONG IN SUPERBLK >> SALVAGE? [yn] n >> >> SUMMARY INFORMATION BAD >> SALVAGE? [yn] n >> >> BLK(S) MISSING IN BIT MAPS >> SALVAGE? [yn] n >> >> 266075 files, 939314 used, 1896628 free (2724 frags, 236738 blocks, 0.1% >> fragmentation) >> >> * FILE SYSTEM MARKED DIRTY * >> >> * FILE SYSTEM WAS MODIFIED * >> >> * PLEASE RERUN FSCK * >> >> # fsck -F >> ** /dev/ada0s2a >> >> USE JOURNAL? [yn] y >> >> ** SU+J recovering /dev/ada0s2a >> Journal timestamp does not match fs mount time >> ** Skipping journal, falling through to full fsck >> >> ** Last Mounted on / >> ** Root file system >> ** Phase 1 - Check Blocks and Sizes >> INCORRECT BLOCK COUNT I=114700 (8 should be 0) >> CORRECT? [yn] y >> >> INCORRECT BLOCK COUNT I=196081 (32 should be 8) >> CORRECT? [yn] y >> >> INCORRECT BLOCK COUNT I=474381 (32 should be 8) >> CORRECT? [yn] y >> >> ** Phase 2 - Check Pathnames >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> ** Phase 5 - Check Cyl groups >> FREE BLOCK COUNTS(S) WRONG IN SUPERBLK >> SALVAGE? [yn] y >> >> SUMMARY INFORMATION BAD >> SALVAGE? [yn] y >> >> BLK(S) MISSING IN BIT MAPS >> SALVAGE? [yn] y >> >> 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, 0.1% >> fragmentation) >> >> * FILE SYSTEM MARKED CLEAN * >> >> * FILE SYSTEM WAS MODIFIED * >> >> # >> >> Summary: >> 1. # fsck -F ## recovery done with J >> >> 2. # fsck -F ## no recovery; fs marked dirty; time stamp modified >> Why during this step there were incorrect block counts reported if >> the fs >> was recovered and marked clean in step 1 ? >> Despite the fact that choice of no recovery was made, the fs was >> marked >> dirty (based on false assumption above ?, and time stamp ?) >> >> 3. # fsck -F ## forced skipped Journal >> Same question as in step 2, >> based on which it accepted the choice of recovery ... >> Note: >> after step 2: >> 1896628 free and 2724 frags in >> 266075 files, 939314 used, 1896620 free (2724 frags, 236738 blocks, >> ... >> after step 3: >> 1896629 free and 2725 frags in >> 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, >> ... >> >> Questions: >> - is the fsck working properly with SU+J fs ? >> Note: >> fsck(8) >> -F ... >> -B ... >> It is recommended that you perform foreground fsck on your systems >> periodically and whenever you encounter file-system-related panics. >> - would the fs as after step 1, and steps 1-3 or 1,3 be considered >> "recovered": >> - structurally ? >> - identical ?, does it matter ? >> - integrally ? >> >> Any comments before I file a PR# ? >> jb > > SUJ very strange work. > it's can say - "filesystem OK", but, after full boot system crash - file > system have errors... > I disable it on all production hosts, use only on desktop. > If I manually run fsck after crash and unexpected reboot - fsck _always_ > find errors, unhandled by SUJ > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.or
Re: SU+J and fsck problem ?
On 10.03.2012 14:01, jb wrote: Hi, FB9.0-RELEASE; no updates or recompilation. In multi-user mode: $ mount /dev/ada0s2a on / (ufs, local, journaled soft-updates) The fs was in normal state (no known problem, clean shutdown), Booted by choice in single-user mode. # mount /dev/ada0s2a on / (ufs, local, read-only) # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] y ** SU+J recovering /dev/ada0s2a ** Reading 33554432 byte journal from inode 4. RECOVER? [yn] y ** ... ** Processing journal entries. WRITE CHANGES? [yn] y ** 208 journal records in 13312 bytes for 50% utilization ** Freed 0 inodes (0 dirs) 6 blocks, and 0 frags. * FILE SYSTEM MARKED CLEAN # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] n ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=114700 (8 should be 0) CORRECT? [yn] n INCORRECT BLOCK COUNT I=196081 (32 should be 8) CORRECT? [yn] n INCORRECT BLOCK COUNT I=474381 (32 should be 8) CORRECT? [yn] n ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLOCK COUNTS(S) WRONG IN SUPERBLK SALVAGE? [yn] n SUMMARY INFORMATION BAD SALVAGE? [yn] n BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] n 266075 files, 939314 used, 1896628 free (2724 frags, 236738 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED DIRTY * * FILE SYSTEM WAS MODIFIED * * PLEASE RERUN FSCK * # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] y ** SU+J recovering /dev/ada0s2a Journal timestamp does not match fs mount time ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=114700 (8 should be 0) CORRECT? [yn] y INCORRECT BLOCK COUNT I=196081 (32 should be 8) CORRECT? [yn] y INCORRECT BLOCK COUNT I=474381 (32 should be 8) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLOCK COUNTS(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * # Summary: 1. # fsck -F ## recovery done with J 2. # fsck -F ## no recovery; fs marked dirty; time stamp modified Why during this step there were incorrect block counts reported if the fs was recovered and marked clean in step 1 ? Despite the fact that choice of no recovery was made, the fs was marked dirty (based on false assumption above ?, and time stamp ?) 3. # fsck -F ## forced skipped Journal Same question as in step 2, based on which it accepted the choice of recovery ... Note: after step 2: 1896628 free and 2724 frags in 266075 files, 939314 used, 1896620 free (2724 frags, 236738 blocks, ... after step 3: 1896629 free and 2725 frags in 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, ... Questions: - is the fsck working properly with SU+J fs ? Note: fsck(8) -F ... -B ... It is recommended that you perform foreground fsck on your systems periodically and whenever you encounter file-system-related panics. - would the fs as after step 1, and steps 1-3 or 1,3 be considered "recovered": - structurally ? - identical ?, does it matter ? - integrally ? Any comments before I file a PR# ? jb SUJ very strange work. it's can say - "filesystem OK", but, after full boot system crash - file system have errors... I disable it on all production hosts, use only on desktop. If I manually run fsck after crash and unexpected reboot - fsck _always_ find errors, unhandled by SUJ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SU+J and fsck problem ?
Hi, FB9.0-RELEASE; no updates or recompilation. In multi-user mode: $ mount /dev/ada0s2a on / (ufs, local, journaled soft-updates) The fs was in normal state (no known problem, clean shutdown), Booted by choice in single-user mode. # mount /dev/ada0s2a on / (ufs, local, read-only) # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] y ** SU+J recovering /dev/ada0s2a ** Reading 33554432 byte journal from inode 4. RECOVER? [yn] y ** ... ** Processing journal entries. WRITE CHANGES? [yn] y ** 208 journal records in 13312 bytes for 50% utilization ** Freed 0 inodes (0 dirs) 6 blocks, and 0 frags. * FILE SYSTEM MARKED CLEAN # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] n ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=114700 (8 should be 0) CORRECT? [yn] n INCORRECT BLOCK COUNT I=196081 (32 should be 8) CORRECT? [yn] n INCORRECT BLOCK COUNT I=474381 (32 should be 8) CORRECT? [yn] n ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLOCK COUNTS(S) WRONG IN SUPERBLK SALVAGE? [yn] n SUMMARY INFORMATION BAD SALVAGE? [yn] n BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] n 266075 files, 939314 used, 1896628 free (2724 frags, 236738 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED DIRTY * * FILE SYSTEM WAS MODIFIED * * PLEASE RERUN FSCK * # fsck -F ** /dev/ada0s2a USE JOURNAL? [yn] y ** SU+J recovering /dev/ada0s2a Journal timestamp does not match fs mount time ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=114700 (8 should be 0) CORRECT? [yn] y INCORRECT BLOCK COUNT I=196081 (32 should be 8) CORRECT? [yn] y INCORRECT BLOCK COUNT I=474381 (32 should be 8) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLOCK COUNTS(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * # Summary: 1. # fsck -F ## recovery done with J 2. # fsck -F ## no recovery; fs marked dirty; time stamp modified Why during this step there were incorrect block counts reported if the fs was recovered and marked clean in step 1 ? Despite the fact that choice of no recovery was made, the fs was marked dirty (based on false assumption above ?, and time stamp ?) 3. # fsck -F ## forced skipped Journal Same question as in step 2, based on which it accepted the choice of recovery ... Note: after step 2: 1896628 free and 2724 frags in 266075 files, 939314 used, 1896620 free (2724 frags, 236738 blocks, ... after step 3: 1896629 free and 2725 frags in 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, ... Questions: - is the fsck working properly with SU+J fs ? Note: fsck(8) -F ... -B ... It is recommended that you perform foreground fsck on your systems periodically and whenever you encounter file-system-related panics. - would the fs as after step 1, and steps 1-3 or 1,3 be considered "recovered": - structurally ? - identical ?, does it matter ? - integrally ? Any comments before I file a PR# ? jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: newfs/fsck problem (bad superblocks)
See below..
- Bruce Evans's Original Message -
> On Sun, 22 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > > Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
> > > the problem.
> > >
> > > With just a quick review of the patch, I'm not sure I
> > > understand what forces the last dirty buffer to be
> > > written.
>
> This worried me too.
>
> > Try the enclosed patch. It flushes the dirty buffer before
> > program exit and before reading blocks.
>
> There are still some serious (?) overflow bugs.
>
> Index: mkfs.c
> ===
> RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
> retrieving revision 1.29
> retrieving revision 1.30
> diff -c -2 -r1.29 -r1.30
> *** mkfs.c1999/08/28 00:13:50 1.29
> --- mkfs.c2000/10/17 00:41:36 1.30
> ...
> ***
> *** 1341,1344
> --- 1347,1381
> }
> if (Nflag)
> + return;
> + done = 0;
> + if (wc_end == 0 && size <= WCSIZE) {
> + wc_sect = bno;
> + bcopy(bf, wc, size);
> + wc_end = size;
> + if (wc_end < WCSIZE)
> + return;
> + done = 1;
> + }
> + if (wc_sect * sectorsize + wc_end == bno * sectorsize &&
> ^ overflow ^ overflow
I agree it's an overflow, and I'll get a patch in for it. But
from a lucky point of view, since the overflow occurs on both sides
of the test, it's a serendipidoues match which doesn't hurt, or
the match fails, which causes the cache to flush.
> + wc_end + size <= WCSIZE) {
> + bcopy(bf, wc + wc_end, size);
> + wc_end += size;
> + if (wc_end < WCSIZE)
> + return;
> + done = 1;
> + }
> + if (wc_end) {
> + if (lseek(fso, (off_t)wc_sect * sectorsize, SEEK_SET) < 0) {
> ^^^ must cast like this to prevent overflow
Well, the above can overflow, but the probability of it overflowing
when things are working correctly approaches zero :-)
Regardless, we could put in a test to make sure the final offset
computed is valid.
-john
> + printf("seek error: %ld\n", (long)wc_sect);
> + err(35, "wtfs - writecombine");
> + }
> + n = write(fso, wc, wc_end);
> + if (n != wc_end) {
> + printf("write error: %ld\n", (long)wc_sect);
> + err(36, "wtfs - writecombine");
> + }
> + wc_end = 0;
> + }
> + if (done)
> return;
> if (lseek(fso, (off_t)bno * sectorsize, SEEK_SET) < 0) {
>
> Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: newfs/fsck problem (bad superblocks)
On Sun, 22 Oct 2000 [EMAIL PROTECTED] wrote:
> > Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
> > the problem.
> >
> > With just a quick review of the patch, I'm not sure I
> > understand what forces the last dirty buffer to be
> > written.
This worried me too.
> Try the enclosed patch. It flushes the dirty buffer before
> program exit and before reading blocks.
There are still some serious (?) overflow bugs.
Index: mkfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -c -2 -r1.29 -r1.30
*** mkfs.c 1999/08/28 00:13:50 1.29
--- mkfs.c 2000/10/17 00:41:36 1.30
...
***
*** 1341,1344
--- 1347,1381
}
if (Nflag)
+ return;
+ done = 0;
+ if (wc_end == 0 && size <= WCSIZE) {
+ wc_sect = bno;
+ bcopy(bf, wc, size);
+ wc_end = size;
+ if (wc_end < WCSIZE)
+ return;
+ done = 1;
+ }
+ if (wc_sect * sectorsize + wc_end == bno * sectorsize &&
^ overflow ^ overflow
+ wc_end + size <= WCSIZE) {
+ bcopy(bf, wc + wc_end, size);
+ wc_end += size;
+ if (wc_end < WCSIZE)
+ return;
+ done = 1;
+ }
+ if (wc_end) {
+ if (lseek(fso, (off_t)wc_sect * sectorsize, SEEK_SET) < 0) {
^^^ must cast like this to prevent overflow
+ printf("seek error: %ld\n", (long)wc_sect);
+ err(35, "wtfs - writecombine");
+ }
+ n = write(fso, wc, wc_end);
+ if (n != wc_end) {
+ printf("write error: %ld\n", (long)wc_sect);
+ err(36, "wtfs - writecombine");
+ }
+ wc_end = 0;
+ }
+ if (done)
return;
if (lseek(fso, (off_t)bno * sectorsize, SEEK_SET) < 0) {
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: newfs/fsck problem (bad superblocks)
Patch appears to fix the problem. Do you want to
commit it? Peter? me?
Thanks,
John
ps: it would be interesting to add a statistic to determine
how often the cache block is flushed due to size or read
interference. May determine that the cache should be
larger (or smaller). Did you happen to look at this Peter?
- [EMAIL PROTECTED]'s Original Message -
> > Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
> > the problem.
> >
> > With just a quick review of the patch, I'm not sure I
> > understand what forces the last dirty buffer to be
> > written.
> >
> > revert the patch? try to fix it? comments?
>
> Try the enclosed patch. It flushes the dirty buffer before
> program exit and before reading blocks.
>
> - Tor Egge
>
> Index: sbin/newfs/mkfs.c
> ===
> RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
> retrieving revision 1.30
> diff -u -r1.30 mkfs.c
> --- sbin/newfs/mkfs.c 2000/10/17 00:41:36 1.30
> +++ sbin/newfs/mkfs.c 2000/10/22 08:17:05
> @@ -153,6 +153,7 @@
> void rdfs __P((daddr_t, int, char *));
> void setblock __P((struct fs *, unsigned char *, int));
> void wtfs __P((daddr_t, int, char *));
> +void wtfsflush __P((void));
>
> #ifndef STANDALONE
> void get_memleft __P((void));
> @@ -719,6 +720,7 @@
> for (cylno = 0; cylno < sblock.fs_ncg; cylno++)
> wtfs(fsbtodb(&sblock, cgsblock(&sblock, cylno)),
> sbsize, (char *)&sblock);
> + wtfsflush();
> /*
>* Update information about this partion in pack
>* label, to that it may be updated on disk.
> @@ -1309,6 +1311,7 @@
> {
> int n;
>
> + wtfsflush();
> if (mfs) {
> memmove(bf, membase + bno * sectorsize, size);
> return;
> @@ -1330,6 +1333,27 @@
> static char wc[WCSIZE]; /* bytes */
>
> /*
> + * Flush dirty write behind buffer.
> + */
> +void
> +wtfsflush()
> +{
> + int n;
> + if (wc_end) {
> + if (lseek(fso, (off_t)wc_sect * sectorsize, SEEK_SET) < 0) {
> + printf("seek error: %ld\n", (long)wc_sect);
> + err(35, "wtfs - writecombine");
> + }
> + n = write(fso, wc, wc_end);
> + if (n != wc_end) {
> + printf("write error: %ld\n", (long)wc_sect);
> + err(36, "wtfs - writecombine");
> + }
> + wc_end = 0;
> + }
> +}
> +
> +/*
> * write a block to the file system
> */
> void
> @@ -1363,19 +1387,8 @@
> if (wc_end < WCSIZE)
> return;
> done = 1;
> - }
> - if (wc_end) {
> - if (lseek(fso, (off_t)wc_sect * sectorsize, SEEK_SET) < 0) {
> - printf("seek error: %ld\n", (long)wc_sect);
> - err(35, "wtfs - writecombine");
> - }
> - n = write(fso, wc, wc_end);
> - if (n != wc_end) {
> - printf("write error: %ld\n", (long)wc_sect);
> - err(36, "wtfs - writecombine");
> - }
> - wc_end = 0;
> }
> + wtfsflush();
> if (done)
> return;
> if (lseek(fso, (off_t)bno * sectorsize, SEEK_SET) < 0) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: newfs/fsck problem (bad superblocks)
Hi! I've seen the same problem. And I've lost all content of my second hd. After newfs fsck can't check fs with the same diagnostic. Dmitry. On Sat, 21 Oct 2000, John W. De Boskey wrote: > Date: Sat, 21 Oct 2000 21:16:56 -0700 > From: "John W. De Boskey" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Peter Wemm <[EMAIL PROTECTED]> > Subject: newfs/fsck problem (bad superblocks) > > Hi, > >I posted a question concerning fsck yesterday. A number of > people replied with the 'bad harddisk' comment. > >I have followed up some more on the problem, and can now > reproduce it on different filesystems. > >Below, I umount my /usr/obj, newfs it, mount it, unmount > it, and then fsck it. The fsck complains about a bad superblock. > Also, do not remotely reboot after this if the newly newfs'd > filesystem is automounted in /etc/fstab. The boot process > will hang waiting for fsck to be run manually. > >Example: > > + > %umount /usr/obj > %newfs /dev/ccd0a > Warning: 1616 sector(s) in last cylinder unallocated > /dev/ccd0a: 672 sectors in 1628 cylinders of 1 tracks, 4096 sectors > 3255.2MB in 102 cyl groups (16 c/g, 32.00MB/g, 4096 i/g) > super-block backups (for fsck -b #) at: > 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, > 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, > 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, > 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, > 2293792, 2359328, 2424864, 2490400, 2555936, 2621472, 2687008, 2752544, > 2818080, 2883616, 2949152, 3014688, 3080224, 3145760, 3211296, 3276832, > 3342368, 3407904, 3473440, 3538976, 3604512, 3670048, 3735584, 3801120, > 3866656, 3932192, 3997728, 4063264, 4128800, 4194336, 4259872, 4325408, > 4390944, 4456480, 4522016, 4587552, 4653088, 4718624, 4784160, 4849696, > 4915232, 4980768, 5046304, 5111840, 5177376, 5242912, 5308448, 5373984, > 5439520, 5505056, 5570592, 5636128, 5701664, 5767200, 5832736, 5898272, > 5963808, 6029344, 6094880, 6160416, 6225952, 6291488, 6357024, 6422560, > 6488096, 6553632, 6619168 > %mount /dev/ccd0a /usr/obj > %df -m /usr/obj > Filesystem 1M-blocks UsedAvail Capacity Mounted on > /dev/ccd0a 32010 2944 0%/usr/obj > %umount /usr/obj > %/sbin/fsck -y /dev/ccd0a > ** /dev/ccd0a > BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE > > LOOK FOR ALTERNATE SUPERBLOCKS? yes > > USING ALTERNATE SUPERBLOCK AT 32 > ** Last Mounted on > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 1 files, 1 used, 1638914 free (18 frags, 204862 blocks, 0.0% fragmentation) > > UPDATE STANDARD SUPERBLOCK? yes > > > * FILE SYSTEM WAS MODIFIED * > % > + > > > > I am wondering about the following patch : > > peter 2000/10/16 17:41:37 PDT > > Modified files: > sbin/newfs mkfs.c > Log: > Implement simple write combining for newfs - this is particularly useful > for large scsi disks with WCE = 0. This yields around a 7 times speedup > on elapsed newfs time on test disks here. 64k clusters seems to be the > sweet spot for scsi disks using our present drivers. > > Revision ChangesPath > 1.30 +38 -1 src/sbin/newfs/mkfs.c > > > > I will revert this patch tomorrow. I also wonder if this is related > to the 'make release' problems. > > > Comments welcome. > > -John > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newfs/fsck problem (bad superblocks)
> Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
> the problem.
>
> With just a quick review of the patch, I'm not sure I
> understand what forces the last dirty buffer to be
> written.
>
> revert the patch? try to fix it? comments?
Try the enclosed patch. It flushes the dirty buffer before
program exit and before reading blocks.
- Tor Egge
Index: sbin/newfs/mkfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
retrieving revision 1.30
diff -u -r1.30 mkfs.c
--- sbin/newfs/mkfs.c 2000/10/17 00:41:36 1.30
+++ sbin/newfs/mkfs.c 2000/10/22 08:17:05
@@ -153,6 +153,7 @@
void rdfs __P((daddr_t, int, char *));
void setblock __P((struct fs *, unsigned char *, int));
void wtfs __P((daddr_t, int, char *));
+void wtfsflush __P((void));
#ifndef STANDALONE
void get_memleft __P((void));
@@ -719,6 +720,7 @@
for (cylno = 0; cylno < sblock.fs_ncg; cylno++)
wtfs(fsbtodb(&sblock, cgsblock(&sblock, cylno)),
sbsize, (char *)&sblock);
+ wtfsflush();
/*
* Update information about this partion in pack
* label, to that it may be updated on disk.
@@ -1309,6 +1311,7 @@
{
int n;
+ wtfsflush();
if (mfs) {
memmove(bf, membase + bno * sectorsize, size);
return;
@@ -1330,6 +1333,27 @@
static char wc[WCSIZE];/* bytes */
/*
+ * Flush dirty write behind buffer.
+ */
+void
+wtfsflush()
+{
+ int n;
+ if (wc_end) {
+ if (lseek(fso, (off_t)wc_sect * sectorsize, SEEK_SET) < 0) {
+ printf("seek error: %ld\n", (long)wc_sect);
+ err(35, "wtfs - writecombine");
+ }
+ n = write(fso, wc, wc_end);
+ if (n != wc_end) {
+ printf("write error: %ld\n", (long)wc_sect);
+ err(36, "wtfs - writecombine");
+ }
+ wc_end = 0;
+ }
+}
+
+/*
* write a block to the file system
*/
void
@@ -1363,19 +1387,8 @@
if (wc_end < WCSIZE)
return;
done = 1;
- }
- if (wc_end) {
- if (lseek(fso, (off_t)wc_sect * sectorsize, SEEK_SET) < 0) {
- printf("seek error: %ld\n", (long)wc_sect);
- err(35, "wtfs - writecombine");
- }
- n = write(fso, wc, wc_end);
- if (n != wc_end) {
- printf("write error: %ld\n", (long)wc_sect);
- err(36, "wtfs - writecombine");
- }
- wc_end = 0;
}
+ wtfsflush();
if (done)
return;
if (lseek(fso, (off_t)bno * sectorsize, SEEK_SET) < 0) {
Re: newfs/fsck problem (bad superblocks)
> I also wonder if this is related to the 'make release' problems. During "make release", src/release/Makefile does create floppies for installation. Copying 'mfsroot.gz' (mfsroot imagefile) to a newly newfs-ed floppy image (mfsroot.flp, 1.44MB size) causes kernel hungup. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newfs/fsck problem (bad superblocks)
Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes the problem. With just a quick review of the patch, I'm not sure I understand what forces the last dirty buffer to be written. revert the patch? try to fix it? comments? -John - John W. De Boskey's Original Message - > Hi, > >I posted a question concerning fsck yesterday. A number of > people replied with the 'bad harddisk' comment. > >I have followed up some more on the problem, and can now > reproduce it on different filesystems. > >Below, I umount my /usr/obj, newfs it, mount it, unmount > it, and then fsck it. The fsck complains about a bad superblock. > Also, do not remotely reboot after this if the newly newfs'd > filesystem is automounted in /etc/fstab. The boot process > will hang waiting for fsck to be run manually. > >Example: > > + > %umount /usr/obj > %newfs /dev/ccd0a > Warning: 1616 sector(s) in last cylinder unallocated > /dev/ccd0a: 672 sectors in 1628 cylinders of 1 tracks, 4096 sectors > 3255.2MB in 102 cyl groups (16 c/g, 32.00MB/g, 4096 i/g) > super-block backups (for fsck -b #) at: > 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, > 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, > 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, > 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, > 2293792, 2359328, 2424864, 2490400, 2555936, 2621472, 2687008, 2752544, > 2818080, 2883616, 2949152, 3014688, 3080224, 3145760, 3211296, 3276832, > 3342368, 3407904, 3473440, 3538976, 3604512, 3670048, 3735584, 3801120, > 3866656, 3932192, 3997728, 4063264, 4128800, 4194336, 4259872, 4325408, > 4390944, 4456480, 4522016, 4587552, 4653088, 4718624, 4784160, 4849696, > 4915232, 4980768, 5046304, 5111840, 5177376, 5242912, 5308448, 5373984, > 5439520, 5505056, 5570592, 5636128, 5701664, 5767200, 5832736, 5898272, > 5963808, 6029344, 6094880, 6160416, 6225952, 6291488, 6357024, 6422560, > 6488096, 6553632, 6619168 > %mount /dev/ccd0a /usr/obj > %df -m /usr/obj > Filesystem 1M-blocks UsedAvail Capacity Mounted on > /dev/ccd0a 32010 2944 0%/usr/obj > %umount /usr/obj > %/sbin/fsck -y /dev/ccd0a > ** /dev/ccd0a > BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE > > LOOK FOR ALTERNATE SUPERBLOCKS? yes > > USING ALTERNATE SUPERBLOCK AT 32 > ** Last Mounted on > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 1 files, 1 used, 1638914 free (18 frags, 204862 blocks, 0.0% fragmentation) > > UPDATE STANDARD SUPERBLOCK? yes > > > * FILE SYSTEM WAS MODIFIED * > % > + > > > > I am wondering about the following patch : > > peter 2000/10/16 17:41:37 PDT > > Modified files: > sbin/newfs mkfs.c > Log: > Implement simple write combining for newfs - this is particularly useful > for large scsi disks with WCE = 0. This yields around a 7 times speedup > on elapsed newfs time on test disks here. 64k clusters seems to be the > sweet spot for scsi disks using our present drivers. > > Revision ChangesPath > 1.30 +38 -1 src/sbin/newfs/mkfs.c > > > > I will revert this patch tomorrow. I also wonder if this is related > to the 'make release' problems. > > > Comments welcome. > > -John > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newfs/fsck problem (bad superblocks)
Hi, I posted a question concerning fsck yesterday. A number of people replied with the 'bad harddisk' comment. I have followed up some more on the problem, and can now reproduce it on different filesystems. Below, I umount my /usr/obj, newfs it, mount it, unmount it, and then fsck it. The fsck complains about a bad superblock. Also, do not remotely reboot after this if the newly newfs'd filesystem is automounted in /etc/fstab. The boot process will hang waiting for fsck to be run manually. Example: + %umount /usr/obj %newfs /dev/ccd0a Warning: 1616 sector(s) in last cylinder unallocated /dev/ccd0a: 672 sectors in 1628 cylinders of 1 tracks, 4096 sectors 3255.2MB in 102 cyl groups (16 c/g, 32.00MB/g, 4096 i/g) super-block backups (for fsck -b #) at: 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, 2293792, 2359328, 2424864, 2490400, 2555936, 2621472, 2687008, 2752544, 2818080, 2883616, 2949152, 3014688, 3080224, 3145760, 3211296, 3276832, 3342368, 3407904, 3473440, 3538976, 3604512, 3670048, 3735584, 3801120, 3866656, 3932192, 3997728, 4063264, 4128800, 4194336, 4259872, 4325408, 4390944, 4456480, 4522016, 4587552, 4653088, 4718624, 4784160, 4849696, 4915232, 4980768, 5046304, 5111840, 5177376, 5242912, 5308448, 5373984, 5439520, 5505056, 5570592, 5636128, 5701664, 5767200, 5832736, 5898272, 5963808, 6029344, 6094880, 6160416, 6225952, 6291488, 6357024, 6422560, 6488096, 6553632, 6619168 %mount /dev/ccd0a /usr/obj %df -m /usr/obj Filesystem 1M-blocks UsedAvail Capacity Mounted on /dev/ccd0a 32010 2944 0%/usr/obj %umount /usr/obj %/sbin/fsck -y /dev/ccd0a ** /dev/ccd0a BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE LOOK FOR ALTERNATE SUPERBLOCKS? yes USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 1638914 free (18 frags, 204862 blocks, 0.0% fragmentation) UPDATE STANDARD SUPERBLOCK? yes * FILE SYSTEM WAS MODIFIED * % + I am wondering about the following patch : peter 2000/10/16 17:41:37 PDT Modified files: sbin/newfs mkfs.c Log: Implement simple write combining for newfs - this is particularly useful for large scsi disks with WCE = 0. This yields around a 7 times speedup on elapsed newfs time on test disks here. 64k clusters seems to be the sweet spot for scsi disks using our present drivers. Revision ChangesPath 1.30 +38 -1 src/sbin/newfs/mkfs.c I will revert this patch tomorrow. I also wonder if this is related to the 'make release' problems. Comments welcome. -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
