Re: ffsfsn
Alfred Perlstein <[EMAIL PROTECTED]> wrote: > * Dmitry Sivachenko <[EMAIL PROTECTED]> [010406 05:18] wrote: >> Hello! >> >> What does 'ffsfsn' state (shown in top(1) output) mean? >> I am inserting records in Postgres, and the process is going very slowly >> probably due to postgres is in this state... > Looks like part of the file being fsync'd. Did you read the docs > that come with Postgresql? There's an option you need to use to > disable calls to fsync() for each operation that ought to speed > things up for you. might be worth waiting for the soon to be available postgresql 7.1 which has write ahead logging and can thus run quite safe without fsync (in 7.0 running without fsync might be a bit unsafe in case of a crash i think) t -- thomas graichen <[EMAIL PROTECTED]> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
journaling UFS and LFS
is anybody working on adding journaling to the (Free)BSD ufs - or are there any docs in that direction avalibale - any papers or so ? how much harder this is getting due to the complex FreeBSD vm/buffercache and soft updates ? - is anybody intereseted in starting to work on this ? and the next question: now that LFS starts to get usable in NetBSD - has anybody started to look at getting it working again in FreeBSD too (maybe matt ?) or has it on the TODO list for the next months or anything similar ? - anybody with some skills willing to to start working on this ? - just some words about the state in NetBSD (according to my experiments :-): they have it working so far - mostly stable with some minor problems still and also the fsck_lfs is at least able to check the lfs filesystem read only. i think it is a very important point to get this working in FreeBSD due to too long fsck times at bootup getting more and more a killer argument against FreeBSD in serious use with growing filesystem sizes - linux now has somekind of beta quality journaling for ext2 working now btw. t -- [EMAIL PROTECTED] innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mysterious FreeBSD hardware problems
On Sat, 18 Sep 1999, Juha Nurmela wrote: > > Your message at freebsd-hackers: > > Hello, > > This looks like the 'timecounter.method' problem, > with AMD K5 model 0 sugar. > I have had good result from a single patch, > not touching the timecounter stuff, but instead: > > If you can find file sys/i386/i386/switch.s > and there a single operation > hlt > > try deleting that op, recompile/install kernel and reboot > and see what happens. I'm curious to hear about the result. > yes it works perfectly - it solved all the problems at once ... how did you find that solution ? - maybe this should be added as one of the cpu specific options to LINT - so that the next one will find that easier ... a lot of thanks t -- graic...@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mysterious FreeBSD hardware problems
On Sat, 18 Sep 1999, Juha Nurmela wrote: > > Your message at freebsd-hackers: > > Hello, > > This looks like the 'timecounter.method' problem, > with AMD K5 model 0 sugar. > I have had good result from a single patch, > not touching the timecounter stuff, but instead: > > If you can find file sys/i386/i386/switch.s > and there a single operation > hlt > > try deleting that op, recompile/install kernel and reboot > and see what happens. I'm curious to hear about the result. > yes it works perfectly - it solved all the problems at once ... how did you find that solution ? - maybe this should be added as one of the cpu specific options to LINT - so that the next one will find that easier ... a lot of thanks t -- [EMAIL PROTECTED] innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mysterious FreeBSD hardware problems
(sorry if this appears here twice - but as far as i can see the first try didn't make it here due to non optimal configuration of my news to mailinglist gateway :-) i'm a bit at the end of my phantasie with this machine i'm writing this here on ... something mystically seems to be broken with running FreeBSD on it ... first mystical thing is that the moused takes about a minute to start but workes then fine ... ok after that it boots on into x and works - but everything is very slow somehow as if the machine is under heavy load - but it isn't - one other thing noticable is that it produces very high rates of interupts on the serial ports with the mouse sometimes ... ok - and in addition to all this it won't reboot - if i try to reboot it via reboot/halt/shutdown - it starts to kill processes and nothing more happens - but via ctrl-alt-del or an "kill -INT 1" which that does it reboots fine ... has anyone ever seen this on any machine or any idea where this might come from ? - some more details: the machine runs fine with linux - also i've had another machine (different board) with exacly the same symptoms and there turning on apm in the bios and in the kernel fixed the problems all together but on this board i can't turn on apm - because it does not detect the amd cpu and i think thus refuses to turn on apm (it prints apm disabled at bootup even if i set it to enabled in the bios) - i would really like to see FreeBSD running completely on this machine here are some more details - first a "boot -v" output and second a ktrace of the hanging "halt" ... Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-RELEASE #1: Mon Sep 13 05:43:35 CEST 1999 r...@battus.at.home:/usr/src/sys/compile/BATTUS Calibrating clock(s) ... TSC clock: 74378519 Hz, i8254 clock: 1193729 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 74345070 Hz CPU: AMD K5 model 0 (74.35-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x500 Stepping=0 Features=0x3bf real memory = 41943040 (40960K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0027d000 - 0x027fdfff, 39325696 bytes (9601 pages) avail memory = 38395904 (37496K bytes) Found BIOS32 Service Directory header at 0xc00f6f10 Entry = 0xf6f20 (0xc00f6f20) Rev = 0 Len = 1 PCI BIOS entry at 0x6f41 Other BIOS signatures found: ACPI: $PnP: 000f9500 Preloaded elf kernel "kernel" at 0xc027. Preloaded elf module "if_tun.ko" at 0xc027009c. pci_open(1):mode 1 addr port (0x0cf8) is 0x8000384c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=122d8086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x122d, revid=0x01 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 chip0: rev 0x01 on pci0.0.0 CPU Inactivity timer: clocks Peer Concurrency: enabled CPU-to-PCI Write Bursting: enabled PCI Streaming: enabled Bus Concurrency: enabled Cache: 256K pipelined-burst secondary; L1 enabled DRAM: no memory hole, 50 MHz refresh Read burst timing: x-2-2-2/x-3-3-3 Write burst timing: x-3-3-3 RAS-CAS delay: 2 clocks found-> vendor=0x8086, dev=0x122e, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip1: rev 0x02 on pci0.7.0 I/O Recovery Timing: 8-bit 8 clocks, 16-bit 4 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: disabled, B: IRQ12, C: disabled, D: disabled MB0: disabled, MB1: disabled found-> vendor=0x8086, dev=0x1230, revid=0x02 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base 8000, size 4 ide_pci0: rev 0x02 on pci0.7.1 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: 8002 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/sl
mysterious FreeBSD hardware problems
(sorry if this appears here twice - but as far as i can see the first try didn't make it here due to non optimal configuration of my news to mailinglist gateway :-) i'm a bit at the end of my phantasie with this machine i'm writing this here on ... something mystically seems to be broken with running FreeBSD on it ... first mystical thing is that the moused takes about a minute to start but workes then fine ... ok after that it boots on into x and works - but everything is very slow somehow as if the machine is under heavy load - but it isn't - one other thing noticable is that it produces very high rates of interupts on the serial ports with the mouse sometimes ... ok - and in addition to all this it won't reboot - if i try to reboot it via reboot/halt/shutdown - it starts to kill processes and nothing more happens - but via ctrl-alt-del or an "kill -INT 1" which that does it reboots fine ... has anyone ever seen this on any machine or any idea where this might come from ? - some more details: the machine runs fine with linux - also i've had another machine (different board) with exacly the same symptoms and there turning on apm in the bios and in the kernel fixed the problems all together but on this board i can't turn on apm - because it does not detect the amd cpu and i think thus refuses to turn on apm (it prints apm disabled at bootup even if i set it to enabled in the bios) - i would really like to see FreeBSD running completely on this machine here are some more details - first a "boot -v" output and second a ktrace of the hanging "halt" ... Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-RELEASE #1: Mon Sep 13 05:43:35 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/BATTUS Calibrating clock(s) ... TSC clock: 74378519 Hz, i8254 clock: 1193729 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 74345070 Hz CPU: AMD K5 model 0 (74.35-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x500 Stepping=0 Features=0x3bf real memory = 41943040 (40960K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0027d000 - 0x027fdfff, 39325696 bytes (9601 pages) avail memory = 38395904 (37496K bytes) Found BIOS32 Service Directory header at 0xc00f6f10 Entry = 0xf6f20 (0xc00f6f20) Rev = 0 Len = 1 PCI BIOS entry at 0x6f41 Other BIOS signatures found: ACPI: $PnP: 000f9500 Preloaded elf kernel "kernel" at 0xc027. Preloaded elf module "if_tun.ko" at 0xc027009c. pci_open(1):mode 1 addr port (0x0cf8) is 0x8000384c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=122d8086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x122d, revid=0x01 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 chip0: rev 0x01 on pci0.0.0 CPU Inactivity timer: clocks Peer Concurrency: enabled CPU-to-PCI Write Bursting: enabled PCI Streaming: enabled Bus Concurrency: enabled Cache: 256K pipelined-burst secondary; L1 enabled DRAM: no memory hole, 50 MHz refresh Read burst timing: x-2-2-2/x-3-3-3 Write burst timing: x-3-3-3 RAS-CAS delay: 2 clocks found-> vendor=0x8086, dev=0x122e, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip1: rev 0x02 on pci0.7.0 I/O Recovery Timing: 8-bit 8 clocks, 16-bit 4 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: disabled, B: IRQ12, C: disabled, D: disabled MB0: disabled, MB1: disabled found-> vendor=0x8086, dev=0x1230, revid=0x02 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base 8000, size 4 ide_pci0: rev 0x02 on pci0.7.1 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: 8002 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/sla
booting current with ata0 etc.
i've just upgraded one of my machines here at work to -current and enabled the ata stuff - but after rebooting it says "cannot mount root" - earlier then i tried this with -current it was working fine and transparent (i.e. without anything to change from wd0 to ad0) - so the question - did anything of this change ? (btw. the machine is an old 486 with isa ide controller and the disk and cdrom are found fine by the ata driver) a lot of thanks in advance for any hint t -- graic...@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
booting current with ata0 etc.
i've just upgraded one of my machines here at work to -current and enabled the ata stuff - but after rebooting it says "cannot mount root" - earlier then i tried this with -current it was working fine and transparent (i.e. without anything to change from wd0 to ad0) - so the question - did anything of this change ? (btw. the machine is an old 486 with isa ide controller and the disk and cdrom are found fine by the ata driver) a lot of thanks in advance for any hint t -- [EMAIL PROTECTED] innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
(fwd) Re: dynamically growing ffs
wouldn't this be also interesting to see for FreeBSD ? - anyone with the required skills having time to have a look at it ? t -- forwarded message -- From: der Mouse <[EMAIL PROTECTED]> Subject: Re: dynamically growing ffs > Is there anything to prevent someone hacking up fsck_ffs to increase > fs->fs_size and everything else that is calculated from it, in order > to add addotopma; unstriped ccd or raidframe space? "addotopma;"? You need to move your right hand one key left. :-) Well, it's not fsck_ffs, but quite a while ago I wrote a program fsresize to resize FFS filesystems on-disk. It turned up a bug in the rotational layout code, which as I recall was in fsck - my code was not generating correct layout tables, fsck didn't notice, and the kernel panicked. I thought I'd created a version which deliberately corrupts the cylinder group data to force fsck to recompute them, but I can't find it now. (Obviously, it would be better to make fsresize DTRT; since this was discovered (IIRC, credit for this discovery belongs to bouyer) I haven't had time to mess with it much.) Modulo that bug, it's believed to work, and can also shrink filesystems, though this tends to be slow because it (in general) has to move data, not just write new cg header blocks. In case any of you developers want to do anything with it, I've put copies of the program and its manpage in ~mouse on cvs.netbsd.org, under the names fsresize.c and fsresize.8; for the non-developers among you, I'll be happy to mail out copies. der Mouse [EMAIL PROTECTED] 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- end of forwarded message -- -- [EMAIL PROTECTED] innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
(fwd) Re: dynamically growing ffs
wouldn't this be also interesting to see for FreeBSD ? - anyone with the required skills having time to have a look at it ? t -- forwarded message -- From: der Mouse Subject: Re: dynamically growing ffs > Is there anything to prevent someone hacking up fsck_ffs to increase > fs->fs_size and everything else that is calculated from it, in order > to add addotopma; unstriped ccd or raidframe space? "addotopma;"? You need to move your right hand one key left. :-) Well, it's not fsck_ffs, but quite a while ago I wrote a program fsresize to resize FFS filesystems on-disk. It turned up a bug in the rotational layout code, which as I recall was in fsck - my code was not generating correct layout tables, fsck didn't notice, and the kernel panicked. I thought I'd created a version which deliberately corrupts the cylinder group data to force fsck to recompute them, but I can't find it now. (Obviously, it would be better to make fsresize DTRT; since this was discovered (IIRC, credit for this discovery belongs to bouyer) I haven't had time to mess with it much.) Modulo that bug, it's believed to work, and can also shrink filesystems, though this tends to be slow because it (in general) has to move data, not just write new cg header blocks. In case any of you developers want to do anything with it, I've put copies of the program and its manpage in ~mouse on cvs.netbsd.org, under the names fsresize.c and fsresize.8; for the non-developers among you, I'll be happy to mail out copies. der Mouse mo...@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- end of forwarded message -- -- graic...@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
SOFTUPDATES and fsck
hello ... maybe this belongs more to fs than to hackers - but maybe this is the correct place here for it ... i've just read the soft updates paper from: http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ at which the soft updates README's in the FreeBSD tree point and ran across the following lines in the section 5.1 "file system recovery": "With the conventional implementation, the fsck utility must be run on a file system before it can be mounted after any system failure. By guarateeing that the on-disk metadata can always be used safely (except when media corruption destroys live metadata), our soft updates im- plementation lifts this requirement. A file system can be safely mounted and used immedeately after most system failures, but may contain several inconsistencies: * unused blocks may not appear in the free space maps * inode link counts may exceed the numer of associated directory entries * unreferenced inodes may not appear in the free inode maps One can run the fsck utility on the filesystem, when convenient, to reclaim unreferenced ressources and correct link counts. ..." at another point it is mentioned that it should be doable to write an fsck tool which can do those corrections in background while the filesystem is mountet read/write ... now my question: how much of this applies to the soft updates im- plementation in FreeBSD ? - might this eventually open the door to an fsck free bootup after a system crash without having to write a journaled filesystem for FreeBSD ? - i think this is one point which gets more and more important on systems with several 100 gb disk space and thus enormous fsck times after a failure can anyone - who is deep in the details of the FreeBSD soft updates implementation (julian, matt, kirk) give some comments on this ? a lot of thanks in advance t -- [EMAIL PROTECTED] innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SOFTUPDATES and fsck
hello ... maybe this belongs more to fs than to hackers - but maybe this is the correct place here for it ... i've just read the soft updates paper from: http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ at which the soft updates README's in the FreeBSD tree point and ran across the following lines in the section 5.1 "file system recovery": "With the conventional implementation, the fsck utility must be run on a file system before it can be mounted after any system failure. By guarateeing that the on-disk metadata can always be used safely (except when media corruption destroys live metadata), our soft updates im- plementation lifts this requirement. A file system can be safely mounted and used immedeately after most system failures, but may contain several inconsistencies: * unused blocks may not appear in the free space maps * inode link counts may exceed the numer of associated directory entries * unreferenced inodes may not appear in the free inode maps One can run the fsck utility on the filesystem, when convenient, to reclaim unreferenced ressources and correct link counts. ..." at another point it is mentioned that it should be doable to write an fsck tool which can do those corrections in background while the filesystem is mountet read/write ... now my question: how much of this applies to the soft updates im- plementation in FreeBSD ? - might this eventually open the door to an fsck free bootup after a system crash without having to write a journaled filesystem for FreeBSD ? - i think this is one point which gets more and more important on systems with several 100 gb disk space and thus enormous fsck times after a failure can anyone - who is deep in the details of the FreeBSD soft updates implementation (julian, matt, kirk) give some comments on this ? a lot of thanks in advance t -- graic...@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
