Re: harddrive won't mount/boot, superblock can't be fixed.
Owe Jørgensen wrote: try newfs -n partition to list the proper superblock backups for the partition. *ahem*... don't you mean -N? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new FreeBSD-webpage
Tuomo Latto wrote: Yecch. All ugly and businesslike. This is what you'd expect from all sorts of companies that are all marketing and no information. At least the.. uhm.. rustic-looking UGU button is gone. ;) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new FreeBSD-webpage
Yann Golanski wrote: Well, I like the new design very much. It's simpler and has less wha on the front page. The top bar thingy I also like the design better than the old one; congrats to the people who did it. It's more compact, it fits on one page (no need to scroll), it's clearly laid out and it doesn't look as if done by a hungover sysadmin in his lunch break. And it is viewable even in lynx. Of course, some people will always complain about change. ;) Someone has mentioned popup-menus that one typically expects from the menubar-like area at the top. That might be a good idea. Most commercial sites have that, when they have an element that looks like this, so people might expect the FreeBSD page to work like that aswell. All in all: well done. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rebuilding world without physical access
Øystein Holmen wrote: users. Could I just stop apache and follow the canonical way, except I don't go into single user mode? Usually works. I've never rebooted into single-user during the upgrade procedure and haven't encountered any problems in 10 years of doing it that way. Also, often it isn't possible, for example, when using a hosted server w/o remote console access. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stress testing and TIMEOUT - WRITE_DMA
MaXX wrote: started 30 Aug 05). If you have the same problem as us, the fix is easy: [...] Does the problem still exist then with newer versions? Or was it specific to the snapshot around June? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stress testing and TIMEOUT - WRITE_DMA
Anthony Chavez wrote: Sep 6 11:35:27 mybox kernel: ad0: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=8348191 [...] Has anyone who has experienced this pain found solace in 5-STABLE's ATA drivers? Is this with the ATA mkIII patches? I assume you're acquainted with the ATA DMA timeout discussions of the last couple months concerning 5.x. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Mark Kirkwood wrote: FreeBSD's filesystems are very robust should you lose power. This sentence is completely bogus (or at best: wishful thinking) and should be deleted. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
C. Michailidis wrote: Effectively, we are taking a known variable that may fluctuate greatly (disk size) and completely ignoring it during installation. Pretty dumb, no? Obviously, this leaves a bad taste in my mouth. Take it to an extreme and maybe I can convert you to my team. Imagine installing to a disk that is 500 terabytes in size... wouldn't it be odd (to say the least) for sysinstall to allocate some infinitesimally small fraction of the disk to /tmp? Isn't /tmp just a place to store temporary files? Isn't there the *possibility* that you are using your system correctly and yet still want to store a large temporary file? From my experience, 256MB is usually more than enough for /tmp. The /tmp directory isn't typically used to store arbritrary huge datasets but is used only by system utilities, scripts, etc., for storing (small) temporary files. The /tmp directory is often a (virtual-) memory-backed filesystem, and on some systems this is the default setting (Solaris, NetBSD 2), so a developer cannot assume in any case that /tmp will be large. Furthermore, the operating system occupies only a small portion of my large hard drive in my workstation, for example. The rest is occupied by, uhm, user files. It doesn't make sense to scale up the basic filesystems by orders of magnitude relative to disk size. I do agree however, that 256mb might be a bit small for / or /var. Maybe cap those at 1GB (/) for the default settings. The /usr filesystem should be at least 5-6GB for a typical workstation setup, if space permits, but probably not more than 10GB. mkb. P.S.: Please instruct your mail program to wrap lines at about 72 characters, as is conventional. You have lines 700 characters in there, and I had to manually reformat the quoted text, which is annoying. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Mark Kirkwood wrote: FreeBSD's filesystems are very robust should you lose power. This sentence is completely bogus (or at best: wishful thinking) and should be deleted. It's probably correct if you have hw.ata.wc=0 (and are using IDE drives obviously). I'd like to stress the probably. I've already seen unrepairable filesystem corruption with softupdates enabled in the past with good scsi disks at power loss. Furthermore, disabling the write-back cache in a typical consumer (read: typical PC workstation) environment today, with large IDE/SATA drives, is unrealistic because of the severe performance degradation, and might even be counter-indicated due to the increased weartear on the disk, which might significantly reduce the disk's lifetime. Softupdates works only in an idealized environment that doesn't match against reality. In addition, with softupdates there seems to be a much higher probability of losing files, as I have observed.. that is, getting them zero-truncated, or even deleted (which shouldn't happen in that scenario, I'm sure I've seen the results of a bug), than without. Do I still use softupdates? Yes, because of the performance benefit, but I don't treat it as much different than completely asynchronous operation, with the only difference that it's a slightly more resilient in case of a kernel crash (vs. a power outage) and I make frequent backups. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Don Lewis wrote: I'd like to stress the probably. I've already seen unrepairable filesystem corruption with softupdates enabled in the past with good scsi disks at power loss. Did you remember to disable write caching by setting the WCE mode page bit to zero? At least with SCSI, it doesn't seem to affect performance under most workloads. No.. I thought that with SCSI it is ok to leave the cache enabled because SCSI supports some sort of request queueing which doesn't break the order established by softupdates? I've seen this when doing compile, run, panic experiments. The executable that I just compiled would end up with a size of zero after the reboot because it was still cached in RAM and executing from RAM when the machine paniced. The executable was scheduled to be written to disk about 30 seconds after it was compiled and linked, but the machine paniced before the 30 seconds was up. Yes, that would account for the 0-size files but not for ones that got deleted by background fsck, with it logging UNREF FILE messages (and that were files that have definitely NOT had directory entries removed since amongst those were dot-files in my homedir, which I had to restore from backup then, and some others where I have not yet found out which they were..) Softupdates only tries to guarantee that the on-disk file system is in a consistent state at all times, with the possible exception that not all space may be accounted for. It doesn't try very hard, though, nor is it very successful. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Chuck Swiger wrote: PS: Haven't we had this conversation before? Yes, indeed, and I don't want to reopen that issue since that would lead to no new insights (and since I don't have the time atm. to contribute anything I couldn't provide any stuff myself). I was just refuting the claim of very robust filesystem when power goes out in the context of 200GB consumer-grade hardware that this thread was talking about. I think until a satisfactory solution can be found (by making softupdates and/or a journalled filesystem as reliable as possible through mechanisms like write-request barriers and appropriate flushing at these) users who're running FreeBSD on end-consumer hardware (desktop PC as workstation or personal server) should be warned that softupdates does NOT work as described on their hardware and that the filesystem can easily be corrupted when the power goes out, no matter if softupdates is enabled or not. One often sees the softupdates argument being fielded by FreeBSD advocates, typically against Linux users with journalled fs, on web forums, usenet and other less authoritative (and knowledgable) places of discussion, and it is often presented as if it were some kind of magic bullet that makes filesystem corruption impossible. This simply is not so. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Chuck Swiger wrote: Yet you seem willing to spend time discussing the matter...? Because it's somewhat of my pet peeve and I always see the mantra-like repetition of the argument that you have to disable the write-back cache if you want any safety at all, which is a) extremely disadvantageous with today's IDE/SATA drives and hardly feasible in reality, and b) other systems like Windows and Linux can operate much safer with the cache _enabled_, on most drives except the most pathetic ones which are totally broken. One often sees the softupdates argument being fielded by FreeBSD advocates, typically against Linux users with journalled fs, on web forums, usenet and other less authoritative (and knowledgable) places of discussion, and it is often presented as if it were some kind of magic bullet that makes filesystem corruption impossible. Often? Strawman test: can you point out 3 examples by message-id or URL? A Google search finds them quickly: http://www.heise.de/ix/foren/go.shtml?read=1msg_id=7335045forum_id=70615 (german, argument is that softupdates is at least a match for a journalled fs), http://lists.freebsd.org/pipermail/freebsd-questions/2003-June/009967.html (FS + SoftUpdates is much better than journaling!) http://aussatz.antville.org/topics/HowTos/ (german, argument is 1. practically nothing can break when power goes out, and even that you can switch off the machine without any problems, except for losing the files that have been written to in the last seconds. Of course no mentioning of disk cache or any sophistication whatever.) And if you prefer to run a journalled filesystem under Linux instead of softupdates under FreeBSD, by all means, do whatever makes you happy. I don't want to do that (that is, I do want that, of course, if I'm using Linux, but in general I don't care about Linux). The point is, that both Windows and recent Linux make great effort to ensure filesystem correctness by using request barriers and clever flushing, or even complete disabling/reenabling of the cache at these barrier points, even on consumer-grade hardware. While with FreeBSD, the attitude generally seems to be a snobby here's a dime, kid, go buy yourself a real computer. That might work for server hardware but for the typical PC, which is a commodity product, and where one often cannot even select the hardware (be it because your employer puts the machine in your office, or you just order some machine somewhere because tinkering with components until a PC works flawlessly has become a royal PITA and waste of time) and so the operating system generally has to work with normal off-the-shelf hardware, which means, cheap IDE/SATA stuff, and not a super-expensive battery-backed U320 SCSI-RAID with a gratis golden Rolex and 1-year free membership in the Dubai Nad al-Sheba golf club. PS: I don't want a thread to end on a negative note. It would be useful if FreeBSD had a more adaptable method for dealing with drive power management and caching; in particular, for laptops it might be nice to cache data for much longer-- perhaps even hours-- if nothing fsync()s, in order to permit the drive to spin down. My notebook lies to me everytime when the battery is going to be out of juice soon (one of the reason I experience powerouts frequently, when I don't pay attention), so that seems to be somewhat unreliable to me.. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Chuck Swiger wrote: I reiterate my question: have you tried adjusting the syncer sysctl's and seeing whether FreeBSD is more stable in the event of a power failure? No, simply because I have no machine at the moment for experimenting if it takes longer until it eats its filesystem. Besides, as I have said, it is not an acute problem for me at the moment and I was merely pointing out the inadequacy of talking about robust filesystems in the context of softupdates and end-consumer harddrives. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Mark Kirkwood wrote: Would you be happy if the handbook section added a caution, or referred to the section that discusses the write cache? Yes, that would inform the user. (FWIW - I have seen Linux + ext3 systems destroyed by power failure because the admins refused to disable write caching on ATA drives - Neither journelling or softupdates is much help if the HW is kidding you about write acknowledgment). From what I understand from googling around on that issue, the write-barrier stuff should make that much more unlikely. Of course there could be the situation that it was a kernel that did not (properly) support write-barriers yet, or the Linux implementation has/had bugs (not too unlikely), or the disk was so broken that even the flushing workaround strategies were ignored or it otherwise didn't properly flush it, etc. But they're at least trying to cope with the issue. BTW., when have you last seen a broken NTFS? While I don't do Windows much, I have had quite a few crashes on Windows (2000, XP) over the years on various machines, and I always asked myself how it could be that the system is up almost immediately (probably due to log replay) with no discernible filesystem damage. Windows (NT) has been doing the write barrier flush tricks (disabling-/ reenabling the cache for flushing it) for longer than Linux and I would think that this contributes to the fault resilience of NTFS. Not that I would imply that NTFS can't be corrupted, of course. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Jon Dama wrote: Ironically, phk backed out the underlying support for this safety fix from the FreeBSD kernel b.c. it wasn't integrated into the softupdates code whereas in reality the proper course of action would have been to hook it in. :-/ Can it be put into softupdates at all? From what I understand (which is probably a rather sketchy idea of the matter), write barriers work because they are only used here to separate journal writes from data writes (i.e., to make sure the log is written, by flushing the cache, before any filesystem data hits the platters). I've read the softupdates paper some time ago and haven't found similar sequence points where one could insert such flushing. One would have to flush all the time, either continuously or in very short intervals, in order to keep the ordering, which then would amount to the same effects as if one simply disabled the cache. But probably I'm wrong here (I hope). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: badblocks
Augusto Cesar Castoldi wrote: is therer any application similar to badblocks of linux on freebsd? badsect(8) How can I check and mark bad blocks of HD's ? But normally modern drives do that by themselves (and transparently remap them). If the filesystem starts complaining about bad blocks (that is, hard read/write errors), that means the on-disk bad sector list is full and it's probably time to buy a new drive. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: badblocks
Hans Lambermont wrote: How can I check if my drives are configured to do this ? I remember on BSDi that you had to 'switch it on' as it was no default behaviour then. I don't know but on my ATA/SATA disks, smartctl displays a Reallocated_Sector_Ct, which I guess is the number of relocated sectors. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
J. T. Farmer wrote: Those of us who want to switch desktops and light duty servers to FreeBSD will give up and move to Linux. OR back to WinXP. I myself am just waiting for NetBSD 3.0, which will hopefully support the ICH6 SATA stuff I have here (2.0.2 doesn't support it) and then I'll move some machines to it. I don't want to start a flamewar but they seem to have a somewhat higher quality output as of lately.. that is, when they advertise something as working, one can be pretty confident that it actually does work. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg, Radeon X800PRO problem.
Section Device Identifier Card0 Driver ati #VendorName ATI Technologies Inc #BoardName Radeon X800PRO #BusID PCI:5:0:0 EndSection ... (--) Assigning device section with no busID to primary device (WW) RADEON: No matching Device section for instance (BusID PCI:5:0:1) found (EE) No devices detected. Have you tried specifying that BusID as in the commented out line above (only PCI:5:0:1 instead of PCI:5:0:0)? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg, Radeon X800PRO problem.
Yann Golanski wrote: Yes, it gives me the same error. The warning changes the PCI slot to PCI:5:0:0... Anyway, I used an older card. It works. *shrugs* Odd.. I've got an X800SE and it works without problems; don't think there's so much of a difference concerning the Xorg driver with the two cards.. ... Errm! Upon looking at your original mail again.. you're running Xorg 6.7? I don't think it'll work with that version. I had to apply patches back then to get 6.7 to work with my card. Try upgrading to the current version that is in ports (6.8.2 iirc). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
Karl Denninger wrote: SII chipsets were ok in 4.x, but the newer ATA code broke badly with them. I've had a PR open on this since February, and many others have reported similar issues. The problems still exist in the 6.x-BETA releases I've checked out, and are in some cases MORE severe (for me anyway) than they are in 5.4. Well, it doesn't affect just the SII chips.. I see the same on an Intel ICH6 chipset but never after the kernel has mounted the root fs. Sometimes it takes several attempts until it manages to do so, though. The machine works w/o any such problems on other OSes. I've deferred update of another machine (which is a hosted box and cannot afford random hangs at boot) because of general flakeyness of the ATA/SATA code in 5.4 (significantly worse than with 5.3, imho). If these issues don't go away completely soon (in 6.x) I'll have to look for some alternative system which doesn't make such a fuss with mainstream hardware. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: background fsck, softupdates inconsistent state on disk
Xin LI [EMAIL PROTECTED] writes: Are you using IDE disk driver? If so, having hw.ata.wc=0 in your /boot/loader.conf would help the SoftUpdates situation. This won't help in the case when the kernel crashes; this (ugly) workaround only helps at a power loss. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0BETA1 - Oddness with install floppies
Alex Burke wrote: I was trying to boot a system from the installation floppies, and after the kernel booted it dropped me out into a mountroot prompt. I am posative its not meant to do this, it should start sysinstall. I am not exactly sure what to do from here on, should i specify ufs:da0s1a...would that be the location of the memory disk? There were no ATA timeout messages? Otherwise, this would indicate that the nasty ATA bugs are on 6.0 still. I have (on 5.4-stable) to try a boot several times until the kernel properly recognizes my drive, and it dumps me in the mount root prompt when it doesn't. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quality of FreeBSD
[EMAIL PROTECTED] writes: My main problem, and to others after seeing the question from times to times, is to know which is a good (not necessarly the best) hardware to run FreeBSD on? When I buy a new motherboard, which chipset to choose/avoid, which controllers ? Maybe some website like it is being done for notebooks (with Linux/FreeBSD support) would be in order. I'm thinking about something like http://www.linux-laptop.net/, only for FreeBSD and all kinds of machines, not just notebooks. (Or, if some collaboration would be ok, for *BSD in general, with people posting experience from NetBSD, OpenBSD, Dragonfly, even Darwin aswell. That way one could also compare support for hardware and see what problems the individual systems have.) Make it a Wiki, or something similar, where people can freely post experiences they have with their hardware. That could be whole machines (Dell model xxx desktop, IBM yyy laptop, HP zzz server) aswell as components (Asus blah motherboard, 3Com wlan card model foobar, etc.) and make the thing searchable, and perhaps allow one to post comments on entries (easy with a Wiki). That way people can quickly search review hardware, awell as test suggested workarounds by the posters, without having to google for obscured mailing list entries, or problem reports. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Oliver Fromme [EMAIL PROTECTED] writes: buffers to disk. While it is doing that, it displays the number of remaining buffers, with increasing time intervals between them. If there are still buffers left after a certain number of intervals without change, the kernel gives up. Why is it doing this? Can't it just enumerate the buffers and write them, one by one? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Paul Mather [EMAIL PROTECTED] writes: Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. So the kernel is relying on guesswork whether the buffers are flushed or not... You can enumerate the buffers and *try* to write them, but that doesn't guarantee they will be written successfully any more than observing the relative number left outstanding. That's rather nonsensical. If I write each buffer synchronously (and wait for the disk's response) this is for sure a lot more reliable than observing changes in the number of remaining buffers. I mean, where's the sense in the latter? It would be analogous to, in userspace, having to monitor write(2) continuously over a given time interval and check whether the number it returns eventually reaches zero. That's complete madness, imho. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Nicolas Rachinsky wrote: The track which is corrupted could contain data that wasn't written to in months. How would the journal help? I don't understand this question. The track destroyed could contain sectors which are in no way related to the sectors the OS is writing to. And in what way is that related to the existence or nonexistence of write barriers and a journal? If you pound the disk with a hammer, it will most likely break, no matter what strategy you're using. That you cannot eliminate _all_ sources of error with a strategy doesn't mean that you shouldn't implement it to minimize the number of errors that could happen. Besides, I always thought that (most) disks had enough power reserve to be able to write at least one track when power goes away? Or is that an urban myth, I don't know for sure. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
David Taylor wrote: No. I'm just asking if you know of ANY ata drives that will wait for the cache to be flushed before claiming the disable cache command has succeeded. I don't, but I haven't looked. I don't know either. I assume that they do. Does it matter? I mean, I'm not suggesting a frivolous new theory that is highly speculative and warrants a lengthy debate on its purported merits. What I described is common practice on Windows, Linux and probably a few other systems and I would think that they're not doing this for nothing. And, frankly, I'm a bit astonished that the FreeBSD (community) seems to be so ignorant of well-known measures for improving data safety on consumer-grade desktop hardware. Does that mean that FreeBSD is deemed generally unsuited for desktop and laptop use and should be reserved for servers with the appropriate (expensive) hardware? I hope not. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Bill Vermillion wrote: You can fsck a mounted file system and fsck will run in read-only mode. That way you can check for problems, and if there is something wrong you can shutdown and restart. FreeBSD will NOT run fsck in anything other than READ ONLY when the file system is mounted I thought fsck on a live (read-write) filesystem almost always brings up errors (although only of a certain kind, like dangling inodes) unless the fs has been completely quiescent for a while. A quick check seems to confirm this: ** /dev/ad4s3a (NO WRITE) ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=94257 OWNER=mkb MODE=100600 SIZE=2397 MTIME=Jul 16 16:25 2005 CLEAR? no And in the old days when drives were smaller and slower and perfomance needed to be maximized, from about Verision III through System V you could run fsck -S device from cron!! The -S flag was interesting in that it would actually re-write the freelist IF AND ONLY IF there was no corruption on the drive. I'm amazed that this worked.. considering that the fsck would have to be atomic then (i.e., basically halt all filesystem i/o while it's running). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Rick Kelly wrote: The main reason for sync;sync;sync on V7 UNIX was because you couldn't do a shutdown, only a halt to the hardware monitor, on the PDP11. You can verify that behavior with SIMH. :-) Uhm.. that's the same on the VAX.. in what way would that preclude a shutdown? NetBSD certainly shuts down on VAX (and drops into the monitor when it's done.) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Paul Mather wrote: on reboot. (Actually, what I find to be more inconvenient is the resynchronisation time needed for my geom_mirror, which takes a lot longer than a fsck.) I understand that fsck delays for large file systems is the major impetus behind the journalling work, not as a fix for a perceived data consistency problem. Well... I have lost a few (ca. 3) UFS filesystems due to power loss or a kernel crash in the past but interestingly those were all on SCSI (and in the pre-softupdates era, so mounted with sync metadata updates, where this Shouldn't Happen[tm] either..) I've also seen ext2fs (which doesn't have safeguards against fs corruption) on Linux zapped often by power loss and haven't seen a statistically higher number of corrupted ext2fs than ufs. So the whole thing is a bit hard to quantify. However, I'm all for reducing the possibility of corruption when it could be done, programmatically. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Lowell Gilbert wrote: Well, break it down a little bit. If an ATA drive properly implements the cache flush command, then none of the ongoing discussion is Are you sure this is the case? Are there sequence points in softupdates where it issues a flush request and by this guarantees fs integrity? I've read thru McKusick's paper in search for an answer but haven't found any. All I've read so far on mailing lists and from googling was that softupdates doesn't work if the wb-cache is enabled. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
John-Mark Gurney wrote: With non-written to sectors getting trashed with the cache enabled, barriers don't mean squat... Of course if you pound the disk with a hammer, then barriers also won't help. Just because with a few disks perhaps it won't work at all doesn't mean that one shouldn't at least try and get it working for perhaps the 90% where it would work in order to reduce the possibility of corruption by as much as possible. I mean, anything is better than the current situation where apparently nothing is done at all. Why am I arguing in an uphill battle here? Is data safety no longer important to the FreeBSD community? Such issues should not even have to be discussed at all! mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
John-Mark Gurney wrote: even request barries will not save the fs in a power loss if the track that is getting flushed durning a power loss... Some other FreeBSD folk has a reproducable case of where blocks that were not written to on ATA hardware got trashed after a power loss... With non-written to sectors getting trashed with the cache enabled, barriers don't mean squat... One more thought.. they _do_ protect against power loss during writing a track -- when used in combination with a journalled fs. A corrupted journal can be detected. If it's corrupted, discard the whole thing, or only the relevant entry. The filesystem will remain consistent. If track corruption occurs after the journal is written, it doesn't matter, since at boot the journal will be replayed and all operations will be performed once more. The combination barriers+journal really seems to be very resilient to filesystem corruption. When it's implemented without errors, and the hardware doesn't do things like change bits randomly, I can't think of a way this scheme can be corrupted at all. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Chuck Swiger wrote: If sysctl hw.ata.wc=0 doesn't do what you want, please submit a PR containing something better. Or buy SCSI hardware and a real, Well, if I had the time, I would. Also if instead of softupdates, a proper journalled filesystem implementation with kernel support for write barriers in the block drivers had been implemented, we wouldn't have this problem now. Ok, no point in arguing how things would be if one had made different decisions in the past. battery-backed up RAID system, or fibre-channel, or Firewire, or whatever floats your boat. I would think that a significant part of (FreeBSD-) users are running FreeBSD on desktop PCs, notebooks, etc., where a fibre-channel or SCSI solution isn't really feasible (either technically, or economically). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Wilko Bulte wrote: sigh Not If The Bloody PeeCee Style Crap ATA Drives Keep Lying To You.. Followups to /dev/null Yes, makes no sense talking to a wall. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Kevin Oberman [EMAIL PROTECTED] writes: I believe that the Windows solution to this problem is to put a really, really long delay between when the system is finished syncing and when the power is turned off. This might be the best solution for FreeBSD, as well, but it will irritate people. The Windows solution is, apparently, to disable and immediately re-enable the writeback-cache around a barrier. This will ensure the cache being written out to the platters, even if the drive ignores a flush command. Of course I don't know this for certain but have to rely on observations that others have made. See, for example: http://mail-index.netbsd.org/tech-kern/2002/12/09/0052.html The long delay at shutdown would simply be a final safeguard in case the drive also ignores disabling of the WC. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Lowell Gilbert [EMAIL PROTECTED] writes: We keep trying to point out that barriers *can't* be enforced on the hardware with many (most, and apparently an increasing percentage of) ATA drives. There is no semantic on these drives that allows you to guarantee the journal block will be written before the corresponding data block. If you are sure that your drives do this properly, then you are safe, but in that case there's no reliability problem with softupdates, either. See my other mail(s) about other systems using cache disabling/enabling to make up for a drive that ignores (or does not implement) a flush command. Then the advice of disable the wb-cache on disks to ensure data safety doesn't make sense: Either * the drive supports disabling the write-back-cache, then this method can be used to flush data to the platters, or else * the drive does not support disabling the write-back-cache, or lies about it, then the advice to disable the write-back-cache for softupdates is meaningless. I know my drive allows disabling of the write cache, as, apparently, the majority of IDE/SATA drives do. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
David Taylor [EMAIL PROTECTED] writes: A corrupted journal can be detected. If it's corrupted, discard the whole thing, or only the relevant entry. The filesystem will remain consistent. If track corruption occurs after the journal is written, it doesn't matter, since at boot the journal will be replayed and all operations will be performed once more. The track which is corrupted could contain data that wasn't written to in months. How would the journal help? I don't understand this question. I still don't trust ATA drives. Can you guarantee (or show any reason to believe) that disabling the write cache will actually wait for the cache to be flushed before returning? Otherwise a disable cacheenable cache sequence is exactly the same as a flush cache command. If the drive executes both immediately, without waiting for the cache to be flushed _before_ returning, what's the difference? You imply that, because there exists one drive for which it doesn't work, that it follows that it won't work for all drives? Or what is your point? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Kevin Oberman wrote: How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. You do NOT want to do that. Not only will performance drop brutally (example: drop to 1/5th of normal write speed for sequential writes, probably worse for random writes) but it will also significantly reduce the lifetime of your disk. Modern disks are designed to be used with the write-back cache enabled, so don't turn it off. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). Until a journalled fs that uses write request barriers is available for FreeBSD, you better had a reliable UPS. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
David Sze wrote: Until a journalled fs that uses write request barriers is available for FreeBSD, you better had a reliable UPS. How do OS-level request barriers help if the disk reorders pending writes in its cache? By separating journal updates from the corresponding metadata (and/or data) actions, and by guaranteeing (by flushing the cache, or a singular disabling/enabling of the wb cache at the barrier) that the journal is updated on disk before the actions take place. This imposes an ordering on the journal vs. action requests, which is what a journalled fs needs for filesystem integrity. It doesn't really matter if the disk reorders writes within those two blocks, the only thing that really matters is that the journal update is completed before metadata (or data) updates take place. With softupdates, as far as I understand, that doesn't work, because there is no journal. All requests must be in the order that softupdates decrees. You'd have to issue a barrier request after every write request, which would be equivalent to disabling the wb cache. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Jon Dama wrote: Request Barriers under linux exist to prevent the low level kernel block device layer from reordering write operations from the upper file system layers. Request Barriers consist of nothing more than tagging internal queues within the Linux kernel itself. They do nothing to resolve the underlying failures of the hardware to provide proper semantics to the block device layer. but, Request Barriers are ultimately useless. They can't resolve the underlying problems with ide/sata and there are already exposed semantics for scsi. If you flush the cache at barriers, on-disk integrity of the journal vs. metadata updates is guaranteed. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Jon Dama [EMAIL PROTECTED] writes: if the FUA bit in the sata command header is properly respected. if the flush cache command on an ata device is properly respected. if the flush cache command on an ata device is implemented (it's optional) if the flush cache command exists when the ata device was made (it isn't in the earlier versions of the ata spec). or if the write-back cache can be disabled and re-enabled. anyways, your comments about softupdates needing total ordering versus journals needing partial ordering are wrong. softupdates only requires that you do not call 'biodone(x)' until 'x' has been committed to disk. Well. Can it group writes in such a way that flushing would be required only at larger intervals, or can't it? this is 100% compatiable with the specification feature set, IF those semantics are actually present in the hardware. Apparently it is not compatible with the real-world feature set and it should've been clear to the designer(s) of softupdates that write-back caches signal completion while the data is still in the cache. That's the whole purpose of these mechanisms (so they can delay and reorder the writes and write out whole tracks). You should only assume that, in that case, a seperate flush command (or a workaround that amounts to a flush) exists. Any different design assumes an oversimplified black box notion of a drive that does not correspond with reality. please see the thread beginning with the following commit message for an extensive discussion of these topics: http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html I've seen nothing that contradicts what I've said. The point is, that the request barrier design with flushing at barriers as used in M$ Windows (and also completed in recent Linux kernels) allows safe use of disks with write-back cache enabled, while FreeBSD with softupdates apparently doesn't. I don't really care how it's implemented, or if journalling is used, or softupdates, or a quantum-tachyon-reverser mounted on the front antenna. I just want to have the same level of data safety on my hardware with FreeBSD that I would get with other systems. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Lowell Gilbert [EMAIL PROTECTED] writes: Jon Dama [EMAIL PROTECTED] writes: however, journaling fairs no better, and request barriers do nothing to solve the problem. I had assumed that the sequence of operations in a journal would be idempotent. Is that a reasonable design criterion? [If it is, then it would make up for the fact that you can't build a reliable transaction gate. That is, you would just have to go back far enough that you *know* all of the needed journal is within the range you will replay. But even then, the journal would need to be on a separate medium, one that doesn't have the lying to you about transaction completion problem.] No, it needn't. It is sufficient that the journal entries for a block of updates that are to follow are on disk before the updates are made. That's all. This can be achieved by inserting a write barrier request in between the journal writes and the actual data/metadata writes. The block driver will, when it sees the barrier, a) write out all requests in its queue that it got before the barrier, and b) flush the cache so that they will not get intermixed by the drive with the following data writes. What could happen now when the power goes away at an inopportune moment? [Note that I'm only talking about filesystem integrity, not general data loss.] * If power goes away before the journal is written, nothing happens. * If the journal is partially written, and power goes away, it will be partially replayed at boot but the filesystem will be consistent. * If power goes away, when the journal is fully written, but no metadata updates have been performed, they will be performed at boot and everything is as if the full request has completed before power went out. * If power goes away when the journal is fully written, and parts of the metadata updates have been written, those updates will be performed twice (once more at reboot) but that won't matter since these operations are idempotent. The remaining metadata updates are then performed once, at reboot. So where is the need for the journal to be on a seperate medium? The only thing that matters is that no metadata updates will be written before the journal has been written, and flushing the disk cache at a barrier will ensure this. Note that the disk doesn't even have to flush the cache when it receives that command, it only has to ensure that it'll perform all requests before the flush in front of those that come afterwards. I have no idea what designed to be used with the write-back cache enabled could affect the operating life of the disk. If you disable the write cache, you get a much higher weartear due to much more seeking. If I observe a 5x performance degradation when the cache is disabled, for sequential writes (i.e., no cache overwriting effects), I would think that I also have a factor 1 of increased seeking operations in the drive, otherwise the performance degradation cannot be explained. [Besides, the disk gets really loud when the cache is disabled.] mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 SATA drive error
Jayton Garnett [EMAIL PROTECTED] writes: Are you using the correct cables? I had a problem when I changed system cases and used the wrong cable when I put the drives back in (IDE cable instead of a SATA cable) I now have FreeBSD 5.4-p3 booting up fine and You mean, an old IDE cable vs. a UDMA-certified IDE cable? It's a bit hard to confuse a SATA cable with an IDE cable, let alone get it into the plug ;). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA support in 5.x ... ?
Marc G. Fournier [EMAIL PROTECTED] writes: How stable is it right now? I was talking with a friend yesterday about it, and he mentioned something about 3 re-write of the code over 2 releases, and that each one wasn't backwards compatible with the other, so you ended up with corrupted file systems ... I'm running on an ICH6 controller (no RAID) with a Seagate disk and don't have any problems, except frequent ATA timeouts at boot (only at boot, before mounting the root fs) but that appeared only after I updated to 5.4-STABLE on June 21 (never seen it before with 5.4-RELEASE or 5.4-STABLE before that date). Once it sucessfully managed to mount its root fs (typically about every 2nd boot attempt), I see no further problems. I'm looking at upgrading my only SATA server to 5.x, since the 4.x that is currently running on it is getting hangs whenever load is put onto the drives :( If you have a server with IDE or SATA, you might also be interested in the write barrier thread that's going on on -questions. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: background fsck can be dangerous!
Niki Denev [EMAIL PROTECTED] writes: Before the background fsck finished some files were unreadable, and they happened to be some libraries used by my mail software. After the fsck finished these libraries were accessible again and everything was normal and working, at least this is what it looked like to me. I wonder how this can happen.. I thought the only thing that could happen is that some files would get truncated to zero length? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4
Tony Byrne [EMAIL PROTECTED] writes: ICH5 must be common in the field along with SATA disks from Western Digital. I would have believed faulty hardware to be the cause, but I have *three* machines that are capable of generating DMA TIMEOUTs while reading or writing SATA disks. In my case here, it's ICH6 and Seagate. Normally this is a good combination that should work flawlessly... I mean, you can't get more conservative than an Intel chipset and a Seagate disk. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: background fsck can be dangerous!
Christian Laursen [EMAIL PROTECTED] writes: Remember that if you are having trouble with softupdates and background fsck reporting inconsistencies, journalling will just give you silent filesystem corruption instead. What makes you believe so? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA problems with FreeBSD 5.4
Joao Carlos Mendes Luis [EMAIL PROTECTED] writes: kernel sends some messages, ata0-master: failure - ATA_IDENTIFY timed out, ata0-master: failure - ATA_IDENTIFY timed out, and them no hard disk is identified, so I cannot install the system. If I boot from a pre-installed hard disk, its even worse, after these message, I get a I've started experiencing the same here, occasionally on reboot, but only after I have upgraded to 5.4-STABLE on June 21. Before, I haven't seen that issue. In a similar situation to yours, Windows XP here has no problems so I don't assume it's hardware related. (And, when it actually boot, the problem doesn't seem occur anymore then while the system is up.) I'm now hesitating to update other machines because of that, hope it gets identified (and fixed) soon. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA_DMA errors (and fs corruption!) (JM)
Jayton Garnett [EMAIL PROTECTED] writes: I had a similar problem and i changed system cases where i was getting a ICRC error and FreeBSD refused to load or even mount the root fs, it was also giving errors with something to do with the ATA something or other, it turned out to be the cable i used after rebuilding the system in the new case, i used a normal EIDE cable instead of a ATA cable :-/ I've just encountered the same problem on 5.4-STABLE/i386. I rebuilt my kernel with SMP and enabled hyperthreading in loader.conf, because the security weakness doesn't really apply to my desktop machine. So, kernel got the DMA error at boot and couldn't mount the root fs. When I switched off HT in the BIOS, the system came up ok. I've cvsupped 5.4-STABLE just a few hours ago. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA_DMA errors (and fs corruption!) (JM)
I wrote: So, kernel got the DMA error at boot and couldn't mount the root fs. Ah, btw.. it's a SATA disk, on an ICH6 SATA150 controller. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't mount partitions with soft-updates enabled with async option
Lefteris Tsintjelis [EMAIL PROTECTED] writes: I am not sure if I do something wrong here or it is suppose to work that way but the async option doesn't seem to work for partitions that have soft-updates turned on. Can someone please clarify the difference and if the speed difference (if any) is significant when using the async option instead of the soft-updates for cases such as the /usr/obj or as a squid data storage? Is async preferred over soft-updates when data loss is not a big issue? With softupdates, everything is asynchronous so the option doesn't make sense. For improving squid filesystem performance, have you mounted the partition with noatime? That might make some difference. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Greg Barniskis [EMAIL PROTECTED] writes: that async provides fast writes at the cost of no guarantee at all for a consistent state of the filesystem. So, you choose: fast but not so reliable writes, or slower writes with fast, reliable disaster recovery. Thanks to the FreeBSD team for choosing the sensible default, even if it results in the occasional Linux is faster! debate. Dang smirky penguins... you're flightless I tell ya, flightless. =) Is CentOS using ext2? I thought everyone moved to ext3 already, which provides nearly the speed of ext2+async but is safe due to its journal. If you make such comparisons, please use current technology, and not the status quo of 5 years ago. [Apart from that, over the last decade, I've lost more UFS filesystems than ext2, so at least for me, that purported unsafety of ext2+async mounts is theoretical at best. In the end, with today's write-caches usually enabled, both are essentially the same, anyways.] mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
David Sze [EMAIL PROTECTED] writes: CentOS uses ext3 by default. How does having a journal help if the journal is stored on the same async filesystem? Unless the journal writes are guaranteed sync. The journal guarantees that the filesystem will always be consistent. If a journal entry doesn't make it to disk, the operation has never happened; and the journal entry won't get removed, until the metadata update has been performed. So the worst thing that could happen is, that the same operation will be performed twice, once normally, and once at log replay on reboot. This is not an issue, since such metadata operations (delete file from directory, write a value into superblock, etc.) are usually idempotent. That's the basic function of all journalled filesystems, and that's why you don't need to run fsck on them. You don't need to write the journal synchronously, you can do these things in groups. The softupdates mechanism does something similar; only it doesn't maintain an on-disk journal, and hence needs fsck after boot to fix up the free block bitmaps and stuff (basically performing a garbage collection on the filesystem, which, unfortunately, is pretty slow). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
David Sze [EMAIL PROTECTED] writes: I'm not sure filesystem consistency alone is good enough. Say your bank's database crashes right after you make a deposit. When it comes back up it's consistent, but only up to 5 minutes before the crash due to the async mount. A bank doesn't run on Unix. It runs on mainframes, with such funny features like processors executing each instruction in parallel, and comparing the results. Completely different universe here. On Unix, filesystem consistency is the best you'll normally get. You _can_ mount filesystems synchronously, both with UFS aswell as ext2/3 etc., but the performance is abysmal. Maybe useful in particular situations but you probably wouldn't want to run your desktop (or busy server) with it. I mean, just try it and see (and make sure writeback-caching on the disks is disabled, when possible.) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Andreas Braukmann [EMAIL PROTECTED] writes: That makes your arguments pointless. I wouldn't even think of running a database server on an async mounted filesystem; all the more I wouldn't connect a drive with enabled write cache to a production box. So you remount all filesystems -o sync on your FreeBSD servers? And you're still satisfied with the performance? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? I hope it's not my bank.. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte [EMAIL PROTECTED] writes: Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? And these are the machines where the master account data is stored? It might very well be your bank.. I've browsed a bit.. they seem to be using one (or more) S/390 (zSeries). Although a different branch office indeed seems to have replaced it for a couple pSeries machines with AIX and some Veritas clusters but I don't know what the purpose of this installation is. But in general I'd think that mainframes are still dominant here. From what I've heard, all transactions are also printed, in real-time, on paper (by high-speed lineprinters), so that even when the machines fail completely and lose transaction data, there is still a hardcopy log. At least I hope that this is (still) true. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Andreas Braukmann [EMAIL PROTECTED] writes: no. But I don't mount them async, either. The default noasync in combination with softupdates on disks with disabled write caches is perfectly fine with me. Noasync only makes sense in the absence of softupdates. With softupdates, metadata is written asynchronously (I mean, that's the whole point, or at least half of it.) Besides, I thought you were talking about synchronous mounts (i.e., synchronous metadata _and_ data writes, which for most uses are just impractical). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WAS: FreeBSD MySQL still WAY slower than Linux
Julian Elischer [EMAIL PROTECTED] writes: Hmmm we processed something over a trillion dollars in bank backends last year on FreeBSD 4.8 (plus patches) on rack mounted PCs. And we didn't lose any of them (the dollars that is). Ah! And look where the dollar is now! ;-) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
I wrote: Kris Kennaway wrote: http://www.chesapeake.net/~jroberson/flushbuf.diff Does it work for you on 5.4? The patch seems to work. Cool, that makes a difference like between BTW., is that change being included in 5-STABLE or just for 6-CURRENT? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Steven Hartland wrote: With the patch things are MUCH better. No problems to report and the server is under major load including some heavy disk access as Yeah, no problems here either, so far. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
Vulpes Velox wrote: I just had to try the USB part... other than having to unmount it and remount it, I had no problems. What did you do? I just tried it again, and get: # umount /dev/da0s1 umount: unmount of /ipod failed: Resource temporarily unavailable And that stays that way, until reboot, rendering the da0s1 device unavailable. umount -f produces an instant reset. No panic, nothing, just *zapp* and the machine resets itself. halt gives up on synching buffers after a while (or produces a panic, like I got in earlier attempts), rendering the filesystems unclean on the next boot. That's on 5.4-STABLE of perhaps 1-2 weeks ago. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how can I use all the plugins in mozilla
Maher Mohamed wrote: i instaled the mozilla and the linuxpluginwrapper port but i still get this error messages I suggest using plugger, /usr/ports/www/plugger, which handles a lot of plugins. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
David Hogan wrote: In my time with the Trustix lists, I don't think I came across a serious kernel issue that wasn't caused by either a lack of a preinstalled driver or a bad stick of ram. Would you say that this holds true for FreeBSD? I If that Trustix works for you now well, you'd be careless to migrate now. If it works, why change it? My experience with the 5.x tree so far is that it's ok for a SOHO or private environment but I wouldn't trust it if my money (or job) depended on it. Maybe in a year, or two but not now. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
Freddie Cash wrote: The only problem we've had with FreeBSD 5 is one system running 5.2.1 that ran for over a year just fine, but would not complete a buildworld (hardware has died and it has been retired, so it's not an issue any more). I remember 5.2.1 panicking left and right, on several machines, it was completely unusable. Maybe we just live in different universes. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
Kris Kennaway wrote: I remember 5.2.1 panicking left and right, on several machines, it was completely unusable. Maybe we just live in different universes. Right, it was a developer preview release that was not intended for production use. I know, I have not claimed otherwise. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
Mike Tancsa wrote: I remember 5.2.1 panicking left and right, on several machines, it was completely unusable. Maybe we just live in different universes. Me too, but a lot has changed since 5.2.1 which at the time was I think was called a preview. The topic is 5.4R. What parts of the OS do you feel are not production ready as compared to 4.X ? I won't go into the details here; it has crashed and frozen on me on several occasions, it behaves badly when you do things it does not expect, like pulling a mounted USB stick, it doesn't have working software RAID (Ok, vinum never worked properly but that's a different story), and it's performance is sub-par. I consider it production ready when the new architecture has fully been implemented, GIANT is gone, all those race conditions and deadlocks that seemingly still persist have been fixed, and is has weathered a release or two after that without apparent problems. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
Charles Swiger wrote: Yanking a mounted device out from under Unix has always been a no- no. It would be nice if FreeBSD handled this better, but this problem falls into the operator error: don't do that category. I'm aware that some things have different priority but it is imho inacceptable over the long run, that if you (accidentally) rip out a mounted usb stick, that the system is unable to flush _any_ buffers and panics upon shutdown. This should be fixed, why doesn't the kernel just discard the buffers for the disappeared device? While it is an operator error, users accidentally pulling usb sticks, iPods, etc. is something that just happens (happened to me 3 times already). 5.3 and earlier especially have struck me as being noticably slower than 4.10 or so, but there have been significant improvements since then, and 5.4 and 4.1x seem to be comparable. To do better than a There has been a thread going on here some time ago where I wrote about this. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Re: Show stopper for large disks with 5.4-RELEASE]
secmgr wrote: hanging all IO's to the partition. Scale that upto 1.8TB, and I could see where you could be going nowhere for a good 10 minutes just waiting for the snap to finish. Still better than waiting hours for fsck, but nowhere near the recovery speed of a true journaled system. Seemingly Scott Long is working on journaling for ufs2. http://www.freebsd.org/news/status/report-jan-2005-mar-2005.html#Filesystem-journalling-for-UFS I like softupdates, conceptually (if they work correctly as described, which I do not know) but if ufsj can omit the fsck garbage collection after an unclean boot that would be a great boon. It would be nice if one can in the future chose between softupdates (for smaller filesystems) and journalling (for larger ones), or so. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Re: Show stopper for large disks with 5.4-RELEASE]
I wrote: after an unclean boot that would be a great boon. It would be nice if one can in the future chose between softupdates (for smaller filesystems) and journalling (for larger ones), or so. OTOH, if journalling works really well and painless, like on Linux with the ext2-ext3 migration, then I can't see any point of maintaining softupdates any longer. Better focus on one thing and to it well instead of diluting developer resources. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: http://www.chesapeake.net/~jroberson/flushbuf.diff Does it work for you on 5.4? The patch seems to work. Cool, that makes a difference like between night and day. I can't determine any observable effect of untarring the firefox source anymore to interactive response time (when it's non-disk bound, of course), where before applying the patch, the mouse cursor would jump, audio stutter and I could barely type in xterms. Seems to work perfectly again. Thanks! mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystems not properly unmounted [OT]
Maxi Combina wrote: companies, etc) to move to an open source OS, we must do an effort. I think that there are a lot of linux distros out there that are really easy to use, and even more friendly or beatiful than windows. I dont think that FreeBSD has achieved this. I dont think there is need. FreeBSD is more suitable for a server station, but not for the desktop. I use linux both as server and desktop with excelent results. If you want a Unix desktop, like most likely many people on this mailing list want, or need, you can use FreeBSD aswell as Linux but not Windows (even with things like UWin or Cygwin, it's a pain). I don't understand this we need to compete with Windows on the desktop thing. I've never considered Windows to be particularly useful as a desktop environment, why should the Unix systems compete with it? [And btw., please let's move this discussion to -advocacy, since it doesn't really belong on this list.] mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystems not properly unmounted [OT]
Iulian M wrote: http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.5 it's about the best programing language ... but if you replace programing language with OS it still applys. From the web page: Anyone who argues in favor of one language over another in a purely technical manner (i.e., who ignores the dominant business issues) exposes themself as a techie weenie, and deserves not to be heard. I wouldn't argue that the point the person wants to express doesn't have some truth in it but imho anyone who talks in such a condescending tone about tech weenies when they present logically sound arguments is someone who deserves not to be heard. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystems not properly unmounted
Vulpes Velox wrote: I have had the same problem with fat32 filesystems before also. I have ut2004 installed on a fatpartition on my dualboot machine. To make it accessible so that I can play it in freebsd aswell, I need to mount and unmount the drive from a rc.d script under /usr/local/etc/ rc.d/ to make sure it gets unmount. With out that, it does not properly unmount it. Odd.. I do not see that with msdosfs (vfat/fat32). I have: /dev/ad4s2 on /dos (msdosfs, local) and it always shuts down cleanly. How do you have it mounted? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystems not properly unmounted
Maxi Combina wrote: Hello, I am running freebsd 5.4, and every time I reboot, I get a mesasge when the kernel is mounting the filesystems. It says that the fs were not properly unmounted, and must chek them. Them main concern is with my root partition. I also have en ext3 partition (which I mount as ext2), and the kernel also complains about this ext3 partition. The root partition is automatically checked, but the ext2 partition not! I have to manually run fsck.ext2 and then reboot again... I am _sure_ that I have rebooted in the right way. Well, at least with `reboot' and `halt'. May be this is not the right way? Am I missing something? This is a known issue; explicitly unmount the ext2/ext3 filesystem before shutdown. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystems not properly unmounted
yuval levy wrote: Anyway, I am just trying to stirr some talk and get some attention to an issue which I find important. Maybe somebody with the appropriate skills will read this and fix the issue. Noone complains that people stir things up every now and then.. at least then the developers are reminded of the open PRs (or at least I hope so). ;-) Yet since developer time is a finite resource, I guess they have to enforce a priority ordering (I wouldn't count this particular bug as top priority, it can be easily circumvented by explicit unmounting, and I wouldn't rely on the robustness of the ext2 filesystem on FreeBSD anyways, and, isn't it read-only? I've only used it so far to copy stuff from it, and had been bitten by a 2Gig filesize limit then but that might be fixed by now, so things do indeed move there.) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystems not properly unmounted
Don Lewis wrote: Nope, the ext2fs problem is different. It is caused by ext2fs holding persistent references to disk buffers that causes the kernel shutdown code to to think that not all the dirty buffers have been written to disk and skip unmounting all the file systems. Can't that be changed in a way that the kernel checks that in a per-filesystem granularity instead of seemingly global? I mean, I can understand that a marginal ext2 fs driver can cause problems with ext2 filesystems, but affecting other filesystems aswell in such a way is not nice. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystems not properly unmounted
Don Lewis wrote: That might help to an extent, but would not eliminate the problem. Any file systems between root and the mount point of the ext2 file system would be busy and would not be able to be unmounted. They would still be marked dirty and would need to be fsck'ed after the reboot. Ah, ok. I think I understand how it works.. BTW., does the 2GB limit for files still apply for ext2 (mounted on FreeBSD, obviously)? I think I encountered this on 5.2.1 when ext2 was commented out from the kernel Makefile (as module) and marked as broken but I needed it (this was when I also encountered that won't clean buffers problem in the same way as the OP.) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
Scott Long wrote: No, 4.x is stale enough. If you need help debugging your computer, please let me know and I will personally fix it for you. Sorry for letting some steam out.. I guess I shouldn't answer directly after a crash. Frankly, I don't know what caused it, so just ignore my rant. I cannot provide details since I've got neither a crashdump now (will fix that for next time), nor access to the console. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
Scott Long wrote: Yeah, and what I'm trying to do is smooth the bumps for the long term. The 4.x-5.x transition was simply a gigantic mess for users, and it was largely a function of it being 4+ years in the making. rantIt still _is_ a gigantic mess. My hosted 5.3-stable server just crapped itself for the second time this year, for no apparent reason. I suggest reestablishing 4.x as the production tree and continuing to maintain it for a while, including making releases, and regressing 5.x to what it is and probably will be for quite a while: experimental./rant mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: interrupt total rate irq1: atkbd0 586 0 irq13: npx01 0 irq14: ata0 94 0 irq17: wi054 0 irq20: fxp0 atapci162079 99 irq21: uhci0 ehci0 1 0 irq22: uhci11102 1 lapic0: timer1246549 1994 lapic1: timer1246427 1994 Total2556893 4091 The only relevant conflict I could see is irc 20; but I had already tested that by removing fxp0 from the kernel. I wonder if USB is causing the problem all on its own..since that was the culprit in other situations when it was being triggered by virtue of interrupt sharing. Any chance you can try a non-USB mouse and remove USB from your kernel? Ok, now USB (both uhci and ehci) is gone. The problem is still the same. vmstat -i: interrupt total rate irq1: atkbd01324 3 irq12: psm0 8562 21 irq13: npx01 0 irq14: ata0 94 0 irq17: wi0 381 0 irq20: fxp0 atapci161956154 lapic0: timer 801433 1993 lapic1: timer 801292 1993 Total1675043 4166 To be frank, I do not believe it's got anything to do with locking or interrupts. It somehow seems just like the scheduler is doing a bad job of balancing interactive processes vs. disk i/o. I've seen the same stuff for years on NetBSD (until they changed scheduling around 1.5 or so) and Linux (until 2.4 kernels). During that time FreeBSD didn't exhibit these symptoms and only in 5.x have I seen that kind of behaviour creep back in. Has the classic scheduler been changed somehow? Maybe I should try and see if the problem persists with the ULE scheduler? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
somehow? Maybe I should try and see if the problem persists with the ULE scheduler? No difference with ULE, with the default parameters: kern.sched.name: ule kern.sched.slice_min: 10 kern.sched.slice_max: 142 kern.sched.preemption: 1 mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Perhaps it's something SATA-related? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Perhaps it's something SATA-related? Before restoring my 5.4 dumps after testing -current, I installed fedora3 linux just to verify it isn't somehow the hardware itself. Ok, plain installation from CDs, kernel 2.6.9-1.667smp (default installation kernel). There was absolutely zero noticable lag or any effect on response time on X11 while untarring the same firefox source. So there really seems to be something foul in FreeBSD in that regard. And now for the dumps.. *sigh*. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Freddie Cash wrote: The laptop has an ATI IXP chipset, which means the HD is detected and run as a generic UDMA33 device. The kernel is using the 4BSD scheduler with PREEMPTION enabled, all debugging hints disabled, and all the mpsafe sysctls enabled. Hmm.. maybe the disk (interface) is just too slow to trigger this when running in UDMA33 (and a slow notebook disk).. I have observed it on a SATA Seagate setup (on ICH6 chipset). Just a wild guess. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Scott Robbins wrote: Judging from the forums and various other things, it seems that a lot of people aren't aware of the second NOTES file. (Of course, you can do make LINT while in arch/conf, which I blush to admit, is what I did before I realized the existance of the second NOTES file. :) Hmm, I didn't know about it either, even though it is referenced at the top of the machdep NOTES file (but who reads that stuff.. ;) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (nbench results)
Bohdan Horst wrote: I have 4 identical PC with FreeBSD (2x4.11R and 2x5.4R) Results (/usr/ports/net/benchmarks/nbench): What you're benchmarking here is gcc3 vs. gcc2. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Max Laier wrote: I have seen this on my box. Disabling one of the USB-ports solved the problem. I was seeing very high IRQ-rates. Check $vmstat -i during the process to see if you have abnormal high rate jumps. It might be that we must investigate some of our drivers to play nice with each other. Interrupt rates were normal. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: But are any IRQs shared? Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require the giant lock? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (nbench results)
Bohdan Horst wrote: (5.4O == 4.11 binary on 5.4R) almost identical speed :) Well, that's hardly surprising.. short of minimizing the number of page faults and avoiding TLB/cache shootdowns, what can the OS do to speed up the CPU pipeline? The nbench program doesn't benchmark any OS functions at all (except for loading time). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (nbench results)
Well, that's hardly surprising.. short of minimizing the number of page faults and avoiding TLB/cache shootdowns, what can the OS do to speed up the CPU pipeline? The nbench program doesn't benchmark any OS functions at all (except for loading time). Btw., what these programs aren't completely nonsense, what they are good for is stuff like finding out that the G5 processor in an 1.6ghz iMac has about 1/3 faster floating point performance than a 3ghz pentium-4 (but somewhat lower integer and memory performance). However, it doesn't show that for certain workloads the p4 I tested is much faster than the particular g5 iMac, since it's got double the amount of 2nd level cache (1mb vs. 512K). So the results are always very special and say very little about allround performance. (For example, for numerical stuff, the iMac would be the better choice, except if you have workloads which benefit significantly from a larger cache.) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require the giant lock? I don't think so..but the shared interrupt might still be causing some other problem. Try compiling a kernel without fxp support and see if you still have the interactive problems under disk load. Ok, I now have tried a) with HTT switched off in BIOS, b) with HTT off and without the fxp driver (so that atapci1 is the only driver on irq 20) and c) on a Compaq notebook, all machines running 5.4-stable. Basically, the problem occurs in all 3 scenarios. However, while cases a) and b) don't seem to be any different from the original scenario, it is a lot less pronounced on the notebook (c). In c) the mouse cursor doesn't really jump but only feels a bit like moving thru syrup, and audio playback (from a remote stream) stops only for fractions of a second. in a) and b), when moving the mouse, the mouse cursor literally jumps around on the screen for several seconds many times during disk i/o, and audio playback stops for ca. 1 second pauses and starts stuttering, like in the original scenario. Curiously I apparently can only reproduce it when untarring large archives like firefox/thunderbird. An ordinary find, or removing the stuff again doesn't seem to show any of those symptoms. The machines are: Intel ICH6-based desktop machine, 3ghz p4 ht, sata disk, and Intel 440BX, 850mhz p3 notebook, udma33 ata disk. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: OK, thanks for confirming. The next step is for you to try 6.0 with debug.mpsafevfs=1 on a machine that exhibits the problem under 5.4, so we can test whether the problem is caused by VFS being under Giant on 5.4. I have now built 6.0-current from yesterday's source, verified that debug.mpsafevfs=1, and unpacked the firefox source. Unfortunately your hypothesis didn't hold. In fact, it's a lot worse than on 5.4-STABLE. Plus, even operations like bulk-rm'ing the unpacked firefox tree make X11 crawl and stutter, something that didn't have any observable effect on 5.4-STABLE. Maybe the dmesg output is of some help: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #0: Wed May 25 05:00:48 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf34 Stepping = 4 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x441dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,b14 Hyperthreading: 2 logical CPUs real memory = 1072201728 (1022 MB) avail memory = 1040392192 (992 MB) ACPI APIC Table: DELL 4700 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL 4700on motherboard acpi0: Power Button (fixed) pci_link0: ACPI PCI Link LNKA irq 11 on acpi0 pci_link1: ACPI PCI Link LNKB irq 5 on acpi0 pci_link2: ACPI PCI Link LNKC irq 5 on acpi0 pci_link3: ACPI PCI Link LNKD on acpi0 pci_link4: ACPI PCI Link LNKE irq 9 on acpi0 pci_link5: ACPI PCI Link LNKF irq 10 on acpi0 pci_link6: ACPI PCI Link LNKG irq 9 on acpi0 pci_link7: ACPI PCI Link LNKH irq 3 on acpi0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci1: display at device 0.1 (no driver attached) pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xff80-0xff9f irq 21 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xff60-0xff7f irq 22 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0xff20-0xff3f irq 23 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xffa80800-0xffa80bff irq 21 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: EHCI (generic) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci3: ACPI PCI bus on pcib3 wi0: Intersil Prism2.5 mem 0xd800-0xd8000fff irq 17 at device 1.0 on pci3 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: Ethernet address: 00:0d:54:aa:62:12 fxp0: Intel 82562EZ (ICH6) port 0xccc0-0xccff mem 0xdfbff000-0xdfbf irq 20 at device 8.0 on pci3 miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX,
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: pcm0 and uhci3 share an interrupt on your system, and both are under Giant, so they'll fight over it when one receives an interrupt, and nothing else can run in the kernel when that is happening. Do you need USB support? If not, get rid of it. Well.. the USB mouse needs it, I guess... mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Joseph Koshy wrote: You may want to try without options WITNESS, INVARIANTS and INVARIANT_SUPPORT. Ok, I've done this. Symptoms are now about equal to 5.4-STABLE. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: I think it's your mouse fighting with your sound card for Giant. And why does it also happen (if not as badly but still) on my notebook where there's no such conflict? interrupt total rate irq0: clk2959195 99 irq1: atkbd0 34101 1 irq6: fdc0 4 0 irq11: cbb0 cbb1++* 373638 12 irq12: psm0 267 0 irq13: npx01 0 irq14: ata0 374788 12 Total3741994126 mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: irq11: cbb0 cbb1++* 373638 12 What else is on irq11? Hmm.. uhm! uhci0, pcm0, fxp0 and wi0... :-} Is the ++* thing notation for there's more stuff but I won't show you? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: I think it's your mouse fighting with your sound card for Giant. I've now disabled the sound chip in the BIOS, no change. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
