Re: More On Samba And Softupdates
On 11/21/2010 2:16 PM, Adam Vande More wrote: On Sun, Nov 21, 2010 at 10:56 AM, Tim Daneliuk tun...@tundraware.com mailto:tun...@tundraware.com wrote: This drive is being used as a backup drive for all the workstations on this particular network, and reliable is much more important than slightly faster. As someone already said, SU is probably not the culprit here. I've used Samba + SU for a long time with no such problems although I have no current setups to verify. SU substantially increases disk IO, it's not 'slightly faster' it's much faster. The error you see is probably the result of flaky drive or controller as the additional IO provided by SU allows the flakiness to show through. Although from what you describe my choice for the drive would be gjournal + UFS. If you've got a lot of asynchronous IO that's a better solution. It looks like this may have been a loose cable. After reseating the cable and reinitializing the drive, it seems to be fine. I turned on softupdates and all seems well ... Thanks for responding... -- Tim Daneliuk tun...@tundraware.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
More On Samba And Softupdates
The other day I mentioned I had a problem with a Samba-shared drive that was just installed blowing up. When I rebuilt it, I forgot to enable softupdates but the drive seems to be working flawlessly. I understand it is possible to do this after-the-fact with tunefs. Some questions: Do I have to unmount the drive to do it? What benefit will I get if I turn on softupdates? This drive is being used as a backup drive for all the workstations on this particular network, and reliable is much more important than slightly faster. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: More On Samba And Softupdates
On Sun, Nov 21, 2010 at 10:56 AM, Tim Daneliuk tun...@tundraware.comwrote: This drive is being used as a backup drive for all the workstations on this particular network, and reliable is much more important than slightly faster. As someone already said, SU is probably not the culprit here. I've used Samba + SU for a long time with no such problems although I have no current setups to verify. SU substantially increases disk IO, it's not 'slightly faster' it's much faster. The error you see is probably the result of flaky drive or controller as the additional IO provided by SU allows the flakiness to show through. Although from what you describe my choice for the drive would be gjournal + UFS. If you've got a lot of asynchronous IO that's a better solution. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: More On Samba And Softupdates
Tim Daneliuk wrote: The other day I mentioned I had a problem with a Samba-shared drive that was just installed blowing up. When I rebuilt it, I forgot to enable softupdates but the drive seems to be working flawlessly. I understand it is possible to do this after-the-fact with tunefs. Some questions: Do I have to unmount the drive to do it? What benefit will I get if I turn on softupdates? This drive is being used as a backup drive for all the workstations on this particular network, and reliable is much more important than slightly faster. As per man tunefs: The tunefs utility cannot be run on an active file system. To change an active file system, it must be downgraded to read-only or unmounted. The benefit is not just speed, but better concurrent multi-user throughput. Operations which would block other I/O finish sooner so the next task can begin without waiting. I actually run mine with aio_load=YES in loader.conf in conjunction with the following in smb.conf: aio read size = 16384 aio write size = 16384 aio write behind = true block size = 16384 use sendfile = Yes Minor performance tweaks aside, should you continue to see the error(s) described in the other mail I sincerely suspect softupdates is not the culprit. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: More On Samba And Softupdates
On Sun, Nov 21, 2010 at 2:16 PM, Adam Vande More amvandem...@gmail.comwrote: Although from what you describe my choice for the drive would be gjournal + UFS. If you've got a lot of asynchronous IO that's a better solution. Instead of asynchronous, I meant multi-threaded. gjournal + UFS handles concurrency better. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Softupdates And Samba
I installed another SATA drive on a FreeBSD 8.1-STABLE box here last night. After the disk prep, I mounted it and then shared the whole drive via Samba. This morning when I came in, the machine had horked all over itself and I saw this in the log after the reboot: Nov 20 01:06:59 ozzie kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=34066054 3 Nov 20 01:06:59 ozzie kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10 NID_NOT_FOUND LBA=340660543 Nov 20 01:06:59 ozzie kernel: g_vfs_done():ad6s1d[WRITE(offset=174418165760, length=131072)]e rror = 5 Nov 20 02:15:07 ozzie kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=14580695 35 Nov 20 02:15:07 ozzie kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10 NID_NOT_FOUND LBA=1458069535 Nov 20 02:15:07 ozzie kernel: g_vfs_done():ad6s1d[WRITE(offset=746531569664, length=131072)]e rror = 5 I reformatted and remounted the drive and accidentally forgot to enable softupdates. It seems to now be working fine. Is there a known interaction with softupdates and Samba such that I should not use them in this case, or could this just have been a loose cable or something? The drive is pretty new ( 6mo) and it's never been a problem when I used it on an NTFS system previously. TIA, -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Softupdates And Samba
Tim Daneliuk wrote: I installed another SATA drive on a FreeBSD 8.1-STABLE box here last night. After the disk prep, I mounted it and then shared the whole drive via Samba. This morning when I came in, the machine had horked all over itself and I saw this in the log after the reboot: Nov 20 01:06:59 ozzie kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=34066054 3 Nov 20 01:06:59 ozzie kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10 NID_NOT_FOUND LBA=340660543 Nov 20 01:06:59 ozzie kernel: g_vfs_done():ad6s1d[WRITE(offset=174418165760, length=131072)]e rror = 5 Nov 20 02:15:07 ozzie kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=14580695 35 Nov 20 02:15:07 ozzie kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10 NID_NOT_FOUND LBA=1458069535 Nov 20 02:15:07 ozzie kernel: g_vfs_done():ad6s1d[WRITE(offset=746531569664, length=131072)]e rror = 5 I reformatted and remounted the drive and accidentally forgot to enable softupdates. It seems to now be working fine. Is there a known interaction with softupdates and Samba such that I should not use them in this case, or could this just have been a loose cable or something? The drive is pretty new ( 6mo) and it's never been a problem when I used it on an NTFS system previously. TIA, I can't speak to -Stable, as I bounce from -Release to -Release. But I have used Samba with softupdates for years and never experienced any problem which might be related to such a combination. While it exists the possibility of flaky controller/driver bug I would look towards a hardware situation first. First thing I'd do is get a bootable CD with the drive manufacturer's diagnostics on it. Western Digital has a bootable .iso you can download if it happens to be a WD. Do the destructive write all zeros comprehensive test and look for any errors, particularly surface defects. I do this with any used drive before using it again. Oh yeah - swap in a new cable first. Plug it in and out several times to scratch through any thin film layer of corrosion which may have formed on the copper. RAID controller and a so-called Green drive? They are very prone to falling offline, as per: http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=1397 Most of the time you can get away with running a desktop drive on a RAID controller and not have problems, but the potential exists. In lieu of this, you could also install smartmontools and look at the drive with various smartctl tests. I take numbers from smart testing with a grain of salt. I generally see them as an additional data point rather than trying to split hairs into a conclusion. The thing you would be trying to discern here is if the bad sector remap area has filled. When this happens the drive can no longer hide bad sectors from the OS. I'd bet it's something simple like a bad cable. Also recall the first rule of maintenance: If it works, don't Fix It! :-) -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Softupdates on the root partition and RSE's gmirror howto.
I've memorized that one shouldn't use soft-updates on / RSE's excellent howto on setting up a pair of mirrored disks (http://people.freebsd.org/~rse/mirror/) includes this line newfs -U /dev/mirror/gm0s1a which enables softupdates. Is this not quite correct, or am I missing something? Thanks, g. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Journaling vs. Softupdates
Hi all, This is addressed in the FAQ to some extent, but that answer seems incomplete. Apparently one of the Google Summer of Code projects is to add journaling to UFS. When it already has softupdates, why? I've seen benchmarks that seem to indicate that softupdates performs as well or better in most cases, though I have nothing on hand to substantiate that. I thought the only real disadvantages of softupdates were: - harder to code and implement (though this is already done, so should not be an issue) - sometimes deleting files does not free space right away Possibility of data loss, I'm guessing, is the same with either. Filesystem corruption is similarly very unlikely. So why the change? Thanks in advance for any answers. Zev ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Journaling vs. Softupdates
Zev Thompson wrote: Apparently one of the Google Summer of Code projects is to add journaling to UFS. When it already has softupdates, why? I've seen benchmarks that seem to indicate that softupdates performs as well or better in most cases, though I have nothing on hand to substantiate that. I thought the only real disadvantages of softupdates were: - harder to code and implement (though this is already done, so should not be an issue) - sometimes deleting files does not free space right away Possibility of data loss, I'm guessing, is the same with either. Filesystem corruption is similarly very unlikely. So why the change? Thanks in advance for any answers. Large filesystems without journaling take too long to fsck. There's plenty of messages about this out there, otherwise I wouldn't have know the answer :-) --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Softupdates Question
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alex de Kruijff Sent: Thursday, July 14, 2005 4:57 PM To: Scott Sipe Cc: freebsd-questions@freebsd.org Subject: Re: Softupdates Question On Tue, Jun 28, 2005 at 03:40:41PM -0400, Scott Sipe wrote: Hi, At work we're running some rather old accounting software that tells us to disable oplocks and all caheing on our file server (and our clients)--Samba/FreeBSD isn't officially supported (the only platforms that are are Windows Server and Novell--yes, it's old) but we've been running fine on this configuration. The software is sensitive to data caching issues etc, and corruption is occasionally an issue. I have all oplocks disabled for the share in samba, and at the moment I have softupdates disabled on the accounting software mount. My question is, does activating softupdates add any risk of data loss? My guess is no, but I've wanted to play it safe. Our other samba shares all have softupdates enabled and do fine, and speed is becoming somewhat of an issue. No there's no risk of data loss. Yes, there is! Softupdates guarantees a consistent state of meta data. But there is a chance of losing a lot of recent file data changes. An other problem is, that Softupdates cannot know how much data is still in the hard disk's cache and not yet written back. I think it cannot easyly be answered, if it is better in this special configuration to run with or w/o Softupdates. Norbert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Softupdates Question
On Tue, Jun 28, 2005 at 03:40:41PM -0400, Scott Sipe wrote: Hi, At work we're running some rather old accounting software that tells us to disable oplocks and all caheing on our file server (and our clients)--Samba/FreeBSD isn't officially supported (the only platforms that are are Windows Server and Novell--yes, it's old) but we've been running fine on this configuration. The software is sensitive to data caching issues etc, and corruption is occasionally an issue. I have all oplocks disabled for the share in samba, and at the moment I have softupdates disabled on the accounting software mount. My question is, does activating softupdates add any risk of data loss? My guess is no, but I've wanted to play it safe. Our other samba shares all have softupdates enabled and do fine, and speed is becoming somewhat of an issue. No there's no risk of data loss. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Softupdates Question
Hi, At work we're running some rather old accounting software that tells us to disable oplocks and all caheing on our file server (and our clients)--Samba/FreeBSD isn't officially supported (the only platforms that are are Windows Server and Novell--yes, it's old) but we've been running fine on this configuration. The software is sensitive to data caching issues etc, and corruption is occasionally an issue. I have all oplocks disabled for the share in samba, and at the moment I have softupdates disabled on the accounting software mount. My question is, does activating softupdates add any risk of data loss? My guess is no, but I've wanted to play it safe. Our other samba shares all have softupdates enabled and do fine, and speed is becoming somewhat of an issue. thanks, Scott ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
URL on softupdates?
Is there a URL that describes how softupdates work? Thanks, John -- John Conover, [EMAIL PROTECTED], http://www.johncon.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: URL on softupdates?
[EMAIL PROTECTED] (John Conover) writes: Is there a URL that describes how softupdates work? From /usr/src/sys/ufs/ffs/README.softupdates: How Soft Updates Work For more general information on soft updates, please see: http://www.mckusick.com/softdep/ http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
softupdates, adding space to partitions, etc
I just noticed that I didn't create *quite* enough space in my /var partition for accepting somewhat larger email attachments/ messages. i thought softupdates was the way to go, but on reading the handbook online, that's not quite what i thought it was is there any way with 5.2.1 to move around disc space between partitions on the fly ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: softupdates, adding space to partitions, etc
Comrade Burnout [EMAIL PROTECTED] wrote: I just noticed that I didn't create *quite* enough space in my /var partition for accepting somewhat larger email attachments/ messages. i thought softupdates was the way to go, but on reading the handbook online, that's not quite what i thought it was No. Softupdates is a method of improving performance by optimizing writes to the disk ... has no real relation to the space involved. is there any way with 5.2.1 to move around disc space between partitions on the fly ? Definately not on the fly. You _can_ use growfs to increase the size of a filesystem, but you must have unused space on the hard drive to grow your partition first. The more traditional way of solving the problem is to symlink the directory that needs the space to a partition with more space. For example, if you're running out of space in /var/spool, and you've got tons of space in /usr, the following procedure will work: 1) Stop any/all programs that might access /var/spool (best thing to do is shutdown now to go to single user mode) 2) mkdir /usr/spool 3) Compare /usr/spool to /var/spool to ensure that the permissions are identical. Change as needed. 4) cp -Rp /var/spool/* /usr/spool/. 5) mv /var/spool /var/spool.old 6) ln -s /usr/spool /var/spool 7) Reboot or restart any programs that will access /var/spool 8) After a sufficient amount of time to ensure that everything worked OK, you can delete /var/spool.old IMHO, the best way to avoid/deal with this problem is to do the following the next time you install: 1) Make the entire disk one big Vinum partition 2) Make Vinum subdisks for the different partitions you want. Size them accordingly, and _leave_any_unneeded_space_unused_! 3) Later if you find you messed up, Vinum gives you the power to join unused space to an existing subdisk, and you can then use growfs to increase the filesystem size. Hell, you can even add new disks if you fill up the entire disk! HTH -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: softupdates, adding space to partitions, etc
I just noticed that I didn't create *quite* enough space in my /var partition for accepting somewhat larger email attachments/ messages. i thought softupdates was the way to go, but on reading the handbook online, that's not quite what i thought it was is there any way with 5.2.1 to move around disc space between partitions on the fly ? Well, mostly no, but if you happen to have left some unused space contiguous to the partition you have mounted as /var, then you can try using growfs(8) But, really, you should either move some stuff from /var, such as /var/spool in to some larger space and make a symlink to it or just start over with partition sizes rethought out according to your more recent experience of your usage patterns. If you have some large partition sitting there with lots of space, it is easy to move some stuf in to it and make the links. I commonly move /var/spool and /var/log somewhere else because they are the most likely to grow uncontrollably or unexpectedly. I usually make reasonable sized partitions for /, /tmp, /usr and /var and then one big one to hold all the stuff whose size can't be easily guessed (which I usually call either home or work). You should be able to find notes on doing this by searching the mailing list archive. I have posted sets of instructions and have seen some posted by others several times. jerry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: softupdates, adding space to partitions, etc
Jerry McAllister wrote: I just noticed that I didn't create *quite* enough space in my /var partition for accepting somewhat larger email attachments/ messages. i thought softupdates was the way to go, but on reading the handbook online, that's not quite what i thought it was is there any way with 5.2.1 to move around disc space between partitions on the fly ? Well, mostly no, but if you happen to have left some unused space contiguous to the partition you have mounted as /var, then you can try using growfs(8) i don't think i left any unused space sitting around, so it doesn't look like growfs is going to be an option. But, really, you should either move some stuff from /var, such as /var/spool in to some larger space and make a symlink to it or just start over with partition sizes rethought out according to your more recent experience of your usage patterns. not an option right now. i didn't think my partitions through all the way /var is the only problem one. If you have some large partition sitting there with lots of space, it is easy to move some stuf in to it and make the links. I commonly move /var/spool and /var/log somewhere else because they are the most likely to grow uncontrollably or unexpectedly. I usually make reasonable sized partitions for /, /tmp, /usr and /var and then one big one to hold all the stuff whose size can't be easily guessed (which I usually call either home or work). i'm more than familiar with doing it the 'traditional' way -- creating a new dir, say /opt/sysmail/mail and symlinking it to /var/spool/mail. i was hoping there was another way to do it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: softupdates, adding space to partitions, etc
Bill Moran wrote: Comrade Burnout [1][EMAIL PROTECTED] wrote: I just noticed that I didn't create *quite* enough space in my /var partition for accepting somewhat larger email attachments/ messages. i thought softupdates was the way to go, but on reading the handbook online, that's not quite what i thought it was No. Softupdates is a method of improving performance by optimizing writes to the disk ... has no real relation to the space involved. is there any way with 5.2.1 to move around disc space between partitions on the fly ? Definately not on the fly. well, that's why i left it in quotes. on the fly as opposed to reinstalling/ rebuilding partitions. i don't want to have to do a newfw(8) on the partitions and have to try and get all the data back ... i can re-edit partition tables, but i'm not 100% familiar with doing it command-line ( read: not from sysinstall at install time ) so i'd rather not risk goofing the data ... IMHO, the best way to avoid/deal with this problem is to do the following the next time you install: 1) Make the entire disk one big Vinum partition 2) Make Vinum subdisks for the different partitions you want. Size them accordingly, and _leave_any_unneeded_space_unused_! 3) Later if you find you messed up, Vinum gives you the power to join unused space to an existing subdisk, and you can then use growfs to increase the filesystem size. Hell, you can even add new disks if you fill up the entire disk! never used Vinum. seen it mentioned a lot, but never read up on it because i wasn't sure what it was ... guess it's time to do some reading, eh? thanks, -b-- References 1. mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNEXPECTED SOFTUPDATES INCONSISTENCY
Lowell Gilbert wrote: Heinrich Rebehn [EMAIL PROTECTED] writes: I have had the above error 2 times now during fsck after an unclean shutdown. fsck -y yielded tons of entries in lost+found. man (7) tuning says that softupdates guarantees filesystem consistency in case of crash, but thousands of lost files tell a different story. Did i miss anything? Or should i disable softupdates for important data? Make sure you've disabled write caching on the drive firmware itself... Does this also apply for RAID disks (twe)? Also, there is no word about this in man tuning(7). Is this more of a guess or is softupdates definately dangerous with wite cache enabled? I have also used softupdates with 4.9 and did not get these errors. The system is running FreeBSD 5.2.1-RC2 I hope you have read the Early Adopter's Guide: http://www.freebsd.org/releases/5.2R/early-adopter.html Yes i have and after asking others on this list, got the impression that 5.2 is usable for the most common hardware and applications. But now i am seriously considering going back to 4.9 Thanks very much for your reply :-) Heinrich ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: UNEXPECTED SOFTUPDATES INCONSISTENCY
Hi Heinrich Rebehn, you wrote. Make sure you've disabled write caching on the drive firmware itself... HR Does this also apply for RAID disks (twe)? Also, there is no word about HR this in man tuning(7). Is this more of a guess or is softupdates HR definately dangerous with wite cache enabled? I'd say it's the other way round: write cache is dangerous with softupdates. Softupdates itself is certainly better than no softupdates, even if it takes a slight performance drop by disabling write cache. I think you should disable the write cache on the 3ware cache (not sure whether there actually is one, mine don't come with any RAM sockets) anyway as you'll lose all data in there in the event of a crash. Regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNEXPECTED SOFTUPDATES INCONSISTENCY
Gabriel Ambuehl wrote: Hello Heinrich, Sunday, February 22, 2004, 5:00:27 PM, you wrote: Why that? I can imagine that i lose data in case of a power failure, but why in case of a crash? Well I guess the card COULD still commit the data, however, who knows if it actually does it? And why is write cache only dangerous with softupdates, as you wrote above? IIRC softupdates relies on the assumption that when the softupdate changes return, they really ARE on the disk. It's the same with most RDBMS: because they go to great lengths to ensure the journal is in an ok state they need to know for sure that the data they wrote to it actually made it to disk. Since i found no word about disabling write cache in the FreeBSD handbook or in man tuning(7), i would really like to know, if this is just a rumour, or where does it come from? I can't say for sure, but I have little confidence in write caching anyhow. It changes semantics the system relies on, for one. Best regards, Gabriel Gabriel, what you write does make sense, although i really can't understand why this important info is not in the FreeBSD documentation. I have disabled write cache, but i will keep softupdates disabled as well for now, and see how the system behaves. Thanks for your help, Heinrich ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: UNEXPECTED SOFTUPDATES INCONSISTENCY
Hello Heinrich, Sunday, February 22, 2004, 6:49:46 PM, you wrote: what you write does make sense, although i really can't understand why this important info is not in the FreeBSD documentation. I have disabled write cache, but i will keep softupdates disabled as well for now, and see how the system behaves. I think it was in there. But maybe I'm mixing this with Lehey's excellent but somewhat dated Complete FreeBSD. Anyway, I've been using softupdates since they became avalaible and never had a single problem with them. Can't exactly say the same about ata(4) though but Soren was always very helpful when problems arised. Best regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: UNEXPECTED SOFTUPDATES INCONSISTENCY
Hello Heinrich, Sunday, February 22, 2004, 5:00:27 PM, you wrote: Why that? I can imagine that i lose data in case of a power failure, but why in case of a crash? Well I guess the card COULD still commit the data, however, who knows if it actually does it? And why is write cache only dangerous with softupdates, as you wrote above? IIRC softupdates relies on the assumption that when the softupdate changes return, they really ARE on the disk. It's the same with most RDBMS: because they go to great lengths to ensure the journal is in an ok state they need to know for sure that the data they wrote to it actually made it to disk. Since i found no word about disabling write cache in the FreeBSD handbook or in man tuning(7), i would really like to know, if this is just a rumour, or where does it come from? I can't say for sure, but I have little confidence in write caching anyhow. It changes semantics the system relies on, for one. Best regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
UNEXPECTED SOFTUPDATES INCONSISTENCY
Hi list, I have had the above error 2 times now during fsck after an unclean shutdown. fsck -y yielded tons of entries in lost+found. man (7) tuning says that softupdates guarantees filesystem consistency in case of crash, but thousands of lost files tell a different story. Did i miss anything? Or should i disable softupdates for important data? The system is running FreeBSD 5.2.1-RC2 Cheers, Heinrich -- Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-4664 Fax :-3341 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Hardware RAID vs softupdates
Hi, I have a Hardware RAID controller -- Mylex DAC960PG -- on the FreeBSD system. Before I installed the RAID controller card, I use one IDE hdd as the system drive and for other mounted file systems. I have 4 SCSI hdds connect to this controller card. I wonder if I should disable the softupdates feature for the FFS to make the system runs faster. Thanks for your opinion. Michael Lee ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware RAID vs softupdates
At 2003-10-14T09:44:31Z, Michael Lee [EMAIL PROTECTED] writes: I have 4 SCSI hdds connect to this controller card. I wonder if I should disable the softupdates feature for the FFS to make the system runs faster. Out of curiosity, what part of the system do you think would be faster without softupdates? -- Kirk Strauser 94 outdated ports on the box, 94 outdated ports. Portupgrade one, an hour 'til done, 82 outdated ports on the box. pgp0.pgp Description: PGP signature
Re: Hardware RAID vs softupdates
Hi Kirk, Thank you for your reply but I think that you probably misunderstand me. So far as I know, FFS with softupdates support acts quite similar to async. file system. However, hardware based RAID controller card is usually equipped with some cache RAM. In some aspects, RAID controller card acts somewhat like async. file ssytem. I wonder if RAID controller waits for a certain time before it does command write to disk and then this write command then was queued by softupdates Will it be faster if I use softupdates with hardware RAID system ? Thanks! Michael Lee - Original Message - From: Kirk Strauser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 10:12 PM Subject: Re: Hardware RAID vs softupdates At 2003-10-14T09:44:31Z, Michael Lee [EMAIL PROTECTED] writes: I have 4 SCSI hdds connect to this controller card. I wonder if I should disable the softupdates feature for the FFS to make the system runs faster. Out of curiosity, what part of the system do you think would be faster without softupdates? -- Kirk Strauser 94 outdated ports on the box, 94 outdated ports. Portupgrade one, an hour 'til done, 82 outdated ports on the box. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vinum and SoftUpdates
Greg 'groggy' Lehey writes: That's because there's nothing to say about them. What was the cause of the panic? Greg, Thanks for following up. I realise my original post was rather scanty on detail, but I was just wondering about the specific combination of vinum/softupdates. Since you indicate that this combination should not be a problem in itself, I will need to dig deeper. Unfortunately I have only heard about the problems on these servers after the fact. I will need to rebuild their kernels with debugging, etc, as I did on my own box previously, and then wait for another crash and see what gdbmods reveals. I'll be in touch when I have something more useful in the way of clues. Regards, Patrick. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vinum and SoftUpdates
On Tuesday, 16 September 2003 at 17:15:35 +0200, [EMAIL PROTECTED] wrote: Hi folks. I have a few boxes which have recently begun to behave rather badly - frequent panics and lots of errors being spewed out during fsck on reboot. I note that these particular boxes have one thing in common - they have vinum devices which are also mounted with softupdates enabled. Is this OK? Well, panics are not OK. I have not been able to find any mention of softupdates in the vinum man pages. That's because there's nothing to say about them. What was the cause of the panic? Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Vinum and SoftUpdates
Hi folks. I have a few boxes which have recently begun to behave rather badly - frequent panics and lots of errors being spewed out during fsck on reboot. I note that these particular boxes have one thing in common - they have vinum devices which are also mounted with softupdates enabled. Is this OK? I have not been able to find any mention of softupdates in the vinum man pages. Thanks for any pointers. Regards, Patrick. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
HD problem, softupdates issue or nothing to be concerned?
Hi, Several times under heavy disk load (copy/delete large directories, the last stage of CVS update) I got the messages like this last free inode /usr/96318 had -765900 blocks handle_workitem_freeblocks: block count (with different inodes), and then during reboot something about mount pending errors. After reboot fsck didn't show anything wrong, though. Should I be concerned about my HD? This is -CURRENT, with 60Gb IDE HD (WDC WD600JB) on an external CMD649 card. TIA, Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maildir with softupdates
Bill Moran wrote: Attila Nagyn wrote: Is this statement still valid? ext3 is unsafe for maildir, and with softupdates, so is ffs. http://www.irbs.net/internet/postfix/0202/0358.html Yes, I don't think this is true for Soft Updates, unless you take your next statement into account, since a proper MTA will fsync data before saying 250 OK because its programmer will understand POSIX semantics. EXT3 violates POSIX semantics by default (async), specifically SHALL be updated vs. SHALL be marked for update, while Soft Updates doesn't. It's also true that any form of write-caching is unsafe, so disable the caches on your SCSI and ATA hard drives. Simply accept the terrible performance hit if you want super-reliability. SCSI is generally not a problem here, because SCSI supports the ability to disconnect writes. Therefore it doesn't have to cheat with its cache, the way ATA does, in order to ensure that writes are committed to stable storage in the order requested: it merely informs the host of the disconnected write status, and the host software takes care to not issue an out-of-order write request to the tagged command queue. In ATA, the lack of ability to support disconnected writes means that either the drives lie to the caller, or all writes end up serialized through a single request window, instead of one the size of the tagged command queue depth (reads simultaneously outstanding are not a problem for ATA, since they do not require no bus disconnect until completion like writes). In general, some lazy manufacturers do not implement the proper defaults, but they are required by the SCSI II and SCSI III (not final) specification to provide an override for the behaviour in mode page 2. If they don't, you can get them kicked off the GSA schedule and force them to lose all their large government contracts, so they are pretty careful about adherence. Also, make sure you have redundant power supplies, UPSes and a diesel generator out back to cover power problems. If things are built correctly, you don't need these, but these days, hardware is not built correctly, even sCSI hardware, and it's possible that you could lose power during a write and lose sectors other than the one you though you were writing, as it sucks everything into the track buffer to do a read-modify-write of a track at a time. 8-(. In reality, anything comes with a certain amount of risk, and that statement is too vague to be useful. Sure; you also forgot terrorists blowing up the data center where you computer is housed, and a total collapse of the government in the country where it's located, leading to anarchy and looting of aluminum and copper from the wires that make up the power grid, in order to appease the god Trogdor The Burninator. 8-). To my knowledge, ext3 is not unsafe by nature, it is simply unsafe by default because the default mount is async - which will generally be corrupted in the event of hardware failure. UFS+softupdates generally survives hardware failure without corruption, although it has a funny habit of losing files that were saved right before the failure. Result being that you could lose emails. Unless your MTA fsync's and waits for the result before saying 250 OK. On EXT3, it would need to also fsync every directory between the queue directory and the root (which is why qmail is so slow, in general, on POSIX compliant systems, which already guarantee ordering of commits for metadata). However ... even a sync mount can become corrupt in the event of hardware failure, although it's much less likely. Yep; and don't forget those pesky Ebola victims exploding and shorting out the entire RAID array... ;^) ;^). So you need to determine the risk level you're willing to accept as well as the performance you require. And you probably need to do more research than accepting that one-line statement, as it's too vague to properly describe the potential risk/benefits. It's always a question of risk. If the business is designed properly, what's actually happening is that you are betting your job vs. the risk involved, and hoping you win the bet. Some people are happy with paying craps for their money; others need a certain amount of security, and other want a government guarantee. For something like bet-your-business-it-works-email-services, my own personal risk tolerance is low enough that I would eat almost any performance hit in order to obtain guaranteed delivery, because in that case, a single email lost could be as bad for my business as a fire in the copier with a missed 911 call to the fire department. Consider how long your average 1970's business would stay in business without their telephone, and you get the idea: it's all about keeping alive the communications channel between you and your customer. Also, this is off-topic for -CURRENT, please remove -CURRENT from the CCs if you respond. I'm redirecting to -QUESTIONS for future discussion. Replied
Re: maildir with softupdates
Terry Lambert wrote: SNIP In reality, anything comes with a certain amount of risk, and that statement is too vague to be useful. Sure; you also forgot terrorists blowing up the data center where you computer is housed, and a total collapse of the government in the country where it's located, leading to anarchy and looting of aluminum and copper from the wires that make up the power grid, in order to appease the god Trogdor The Burninator. 8-). Ha! And I thought I was the only Strong Bad fan here! SNIP However ... even a sync mount can become corrupt in the event of hardware failure, although it's much less likely. Yep; and don't forget those pesky Ebola victims exploding and shorting out the entire RAID array... ;^) ;^). Yuk ... has this happened to you? SNIP So you need to determine the risk level you're willing to accept as well as the performance you require. And you probably need to do more research than accepting that one-line statement, as it's too vague to properly describe the potential risk/benefits. It's always a question of risk. If the business is designed properly, what's actually happening is that you are betting your job vs. the risk involved, and hoping you win the bet. Some people are happy with paying craps for their money; others need a certain amount of security, and other want a government guarantee. For something like bet-your-business-it-works-email-services, my own personal risk tolerance is low enough that I would eat almost any performance hit in order to obtain guaranteed delivery, because in that case, a single email lost could be as bad for my business as a fire in the copier with a missed 911 call to the fire department. This is interesting to me, since I tell all my customers you can NOT trust email to be mission-critical. Not because of my systems, but because the underlying structure is not reliable (i.e. - the Internet connectivity, the mail server on the other end ... etc) So to consider email a reliable form of communication sounds crazy to me. I lump it in with faxes. Sure, I can set you up with a quality, reliable fax system, but I can't guarantee that the fax machine at the other end will be working, or have paper, or that the fax won't accidentally get mixed in with someone elses faxes and lost. I guess that was the point of my original post, is that if you consider the unreliability of the parts of the system that are beyond your control, the potential unreliability of softupdates isn't really worth worrying about. However, each individual MUST determine the proper risk level for his business. For large businesses with inter-office email where many of those factors _are_ under his control, it's possible that the situation is different. Also, this is off-topic for -CURRENT, please remove -CURRENT from the CCs if you respond. I'm redirecting to -QUESTIONS for future discussion. Replied to questions, per your request, but probably -performance would have been a better overall choice. Possibly, now. But the original question sounded like it belonged on -questions, although the topic is spidering toward -performance. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maildir with softupdates
Attila Nagy wrote: Hello, Is this statement still valid? ext3 is unsafe for maildir, and with softupdates, so is ffs. http://www.irbs.net/internet/postfix/0202/0358.html Yes, It's also true that any form of write-caching is unsafe, so disable the caches on your SCSI and ATA hard drives. Simply accept the terrible performance hit if you want super-reliability. Also, make sure you have redundant power supplies, UPSes and a diesel generator out back to cover power problems. In reality, anything comes with a certain amount of risk, and that statement is too vague to be useful. To my knowledge, ext3 is not unsafe by nature, it is simply unsafe by default because the default mount is async - which will generally be corrupted in the event of hardware failure. UFS+softupdates generally survives hardware failure without corruption, although it has a funny habit of losing files that were saved right before the failure. Result being that you could lose emails. However ... even a sync mount can become corrupt in the event of hardware failure, although it's much less likely. So you need to determine the risk level you're willing to accept as well as the performance you require. And you probably need to do more research than accepting that one-line statement, as it's too vague to properly describe the potential risk/benefits. This reminds me of the days when DOS first got disk-caching via a TSR (what was the name of that thing) and all the IT folks kept saying Don't use it, it's dangerous without understanding why it was dangerous. I used it anyway, because it improved performance considerably. Also, this is off-topic for -CURRENT, please remove -CURRENT from the CCs if you respond. I'm redirecting to -QUESTIONS for future discussion. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maildir with softupdates
Basically, if you want to ensure that email wont get lost, put the maildirs and mail queue on separate partitions and mount them sync. This is what I do. If you have to speed things, try first a battery backed raid controler and enable the write cache on it. Of course, you should always use an UPS and some will say you can take the risk of enabling soft-updates anyway. But realise that if you have only a small load on the mail server, then having the partition mounted sync wont make such a big difference. If you are under high load, when you need performance, you also need to mount sync, as the potential of loss is much greater... just my two cents Raphael Le Mercredi, 23 juil 2003, à 17:38 Europe/Zurich, Bill Moran a écrit : Attila Nagy wrote: Hello, Is this statement still valid? ext3 is unsafe for maildir, and with softupdates, so is ffs. http://www.irbs.net/internet/postfix/0202/0358.html Yes, It's also true that any form of write-caching is unsafe, so disable the caches on your SCSI and ATA hard drives. Simply accept the terrible performance hit if you want super-reliability. Also, make sure you have redundant power supplies, UPSes and a diesel generator out back to cover power problems. In reality, anything comes with a certain amount of risk, and that statement is too vague to be useful. To my knowledge, ext3 is not unsafe by nature, it is simply unsafe by default because the default mount is async - which will generally be corrupted in the event of hardware failure. UFS+softupdates generally survives hardware failure without corruption, although it has a funny habit of losing files that were saved right before the failure. Result being that you could lose emails. However ... even a sync mount can become corrupt in the event of hardware failure, although it's much less likely. So you need to determine the risk level you're willing to accept as well as the performance you require. And you probably need to do more research than accepting that one-line statement, as it's too vague to properly describe the potential risk/benefits. This reminds me of the days when DOS first got disk-caching via a TSR (what was the name of that thing) and all the IT folks kept saying Don't use it, it's dangerous without understanding why it was dangerous. I used it anyway, because it improved performance considerably. Also, this is off-topic for -CURRENT, please remove -CURRENT from the CCs if you respond. I'm redirecting to -QUESTIONS for future discussion. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maildir with softupdates
On Wed, Jul 23, 2003 at 11:38:44AM -0400, Bill Moran wrote: Attila Nagy wrote: Hello, Is this statement still valid? ext3 is unsafe for maildir, and with softupdates, so is ffs. http://www.irbs.net/internet/postfix/0202/0358.html Yes, It's also true that any form of write-caching is unsafe, so disable the caches on your SCSI and ATA hard drives. Simply accept the terrible performance hit if you want super-reliability. Forget Unix, go get VMS or (better) a Tandem ;) -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
A softupdates problem?
Hello, Making a daily server backup, using dump (FreeBSD 4.7R), I keep running into a softupdates problem. That is, prior to backing up a partition (/var), I move a large file (several gigabytes) off that partition. But because of the softupdates effect, the size of that large file is added to the dump-file size, as if it were still on the partition! I have been able to circumvent that, in the past, by waiting a few minutes before starting the dump (until df reflects the correct size). This is not really ideal, though, as I disallow outside connections while in backup (so as not to change the /var partion with log-files being filled and such). Is there not a command to force 'softupdates' to write out its cache immediately? Much obliged, - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A softupdates problem?
On Thu, 3 Jul 2003, Mark wrote: Making a daily server backup, using dump (FreeBSD 4.7R), I keep running into a softupdates problem. That is, prior to backing up a partition (/var), I move a large file (several gigabytes) off that partition. But because of the softupdates effect, the size of that large file is added to the dump-file size, as if it were still on the partition! I have been able to circumvent that, in the past, by waiting a few minutes before starting the dump (until df reflects the correct size). This is not really ideal, though, as I disallow outside connections while in backup (so as not to change the /var partion with log-files being filled and such). Is there not a command to force 'softupdates' to write out its cache immediately? I didn't try, but `sync' should do the job, shouldn't it? Regards Konrad Heuer ([EMAIL PROTECTED]) ___ ___ GWDG / __/__ ___ / _ )/ __/ _ \ Am Fassberg / _// __/ -_) -_) _ |\ \/ // / 37077 Goettingen /_/ /_/ \__/\__//___// Germany ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A softupdates problem?
On Thu, Jul 03, 2003 at 11:15:14AM +, Mark wrote: Making a daily server backup, using dump (FreeBSD 4.7R), I keep running into a softupdates problem. That is, prior to backing up a partition (/var), I move a large file (several gigabytes) off that partition. But because of the softupdates effect, the size of that large file is added to the dump-file size, as if it were still on the partition! I have been able to circumvent that, in the past, by waiting a few minutes before starting the dump (until df reflects the correct size). This is not really ideal, though, as I disallow outside connections while in backup (so as not to change the /var partion with log-files being filled and such). Is there not a command to force 'softupdates' to write out its cache immediately? Hmmm... not an answer to the question you asked, but does not: # chflags nodump your-very-large-file in combination with using the '-h 0' flag to dump(8) let you backup the partition without including the file in question? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: A softupdates problem?
- Original Message - From: Matthew Seaman [EMAIL PROTECTED] To: Mark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 03, 2003 1:23 PM Subject: Re: A softupdates problem? Hmmm... not an answer to the question you asked, but does not: # chflags nodump your-very-large-file in combination with using the '-h 0' flag to dump(8) let you backup the partition without including the file in question? Thanks for the suggestion. :) I will use that. - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Softupdates: df, du, sync and fsck [quite long]
On Sat, 28 Jun 2003 15:12:05 -0400 Bill Moran [EMAIL PROTECTED] wrote: - Hmmm ... not good. A little more research might qualify this problem for a PR. I was thinking that myself :-) - Yikes! Is the machine still responsive? Sometimes you can put the load that - high and still have a functional box. It was way too sluggish. The machine responded eventually but I wouldn't want to run it like that in production (even though I did for half an hour). - I'm guessing by the way the conversation is going that you're able to grab - one of these boxes and make some tweaks. Possibly try putting the spool - directory on a dedicated partition and mounting it async? If the box shuts - down dirty, you'll probably have to newfs the partition before you can use - it again. At least make sure the spool partition is seperate from your log - partition, that should help to mitigate the problem (although you may already - have done that). I've ordered some more disks already. I'm going to split off the spool, the logs and the anti virus scanner (creates a temporary file for every message received). This will definitely help, I'm sure. Still, it doesn't answer the problem with soft updates I've experienced. - I was wondering if maybe the syncs were taking longer than the shutdown process - was willing to wait. It would certainly seem so, or perhaps it just can't sync for some reason. - It may save you some time to look in CVS under the files for the drivers for - the SCSI subsystem as well as the drivers for you specific cards to see if any - commit messages talk about fixing problems like this. Will do. - My experience with background fsck is that the machine is slow as hell while - the background fsck is running. Whether or not this is better or worse than - what you're experiencing with 4.7 is a question only you can answer. I've played around with background fsck on other machines, but I'm not sure it's right for these (very busy) machines. - Well ... I'm really shooting in the dark with these suggestions, but hopefully - there will be something useful. Gratefully received... - -- - Bill Moran Cheers, John. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Softupdates: df, du, sync and fsck [quite long]
Hello Bill, On Fri, 27 Jun 2003 23:53:30 -0400 Bill Moran [EMAIL PROTECTED] wrote: - I don't know what's wrong, but does unmounting and remounting the partition - reclaim the lost space? Alas, I can't umount the partition, my guess is because it is unable to sync (nothing to do with open files, and no error message saying device busy). The command just doesn't return after I've issued it. - If there's a LOT of inodes with problems, it could easily take a while to fix. - Also, if you run fsck without specifying a filesystem to fix, it exhaustively - checks all filesystems. So even if the problem is on /var, it might spend a - long time checking /usr as well. You can work around this by calling fsck - with the filesystem to check. I don't think it's to do with inodes or block size, etc. There's about 2M inodes on /var. A manual fsck on a dirty shutdown on this partition (ignoring the problem in hand) takes a couple of minutes. - If these are production boxes, I'd recommend turning it off until you resolve - the problem. Indeed, I tried that last night on one machine and it put the load through the roof(48). - I don't know if this would qualify as advice, but since nobody else - seems to have any suggestions, I figured I'd throw my thoughts in. - Are you using ATA or SCSI drives? SCSI. - Does issuing a manual sync once you've stopped the spooling process help - any? No. I'd already tried numerous syncs, and of course a clean shutdown tries that too. - Are these all identical mobos ... possibly a BIOS update available? Haven't looked for an update, but I think they're all identical. - These aren't IBM ATA drives are they? I had one of those give me grief for - months (if you look in the archives, you should be able to find details on - which drives caused problems). Alas not! They're straightforward Seagates, which in other machines we use (much lighter load) don't have this problem. - Have you tried updating one of the machines to 4.8 to see if the problem - has been fixed? I haven't tried that yet but will do so. I'm also going to test a 5.1R machine, perhaps the background fsck will help when I alas come to reboot. - Like I said, not good advice, just some ideas for you. All advice and ideas are welcome. - Bill Moran Cheers, John. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Softupdates: df, du, sync and fsck [quite long]
John Ekins wrote: Hello Bill, On Fri, 27 Jun 2003 23:53:30 -0400 Bill Moran [EMAIL PROTECTED] wrote: - I don't know what's wrong, but does unmounting and remounting the partition - reclaim the lost space? Alas, I can't umount the partition, my guess is because it is unable to sync (nothing to do with open files, and no error message saying device busy). The command just doesn't return after I've issued it. Hmmm ... not good. A little more research might qualify this problem for a PR. - If there's a LOT of inodes with problems, it could easily take a while to fix. - Also, if you run fsck without specifying a filesystem to fix, it exhaustively - checks all filesystems. So even if the problem is on /var, it might spend a - long time checking /usr as well. You can work around this by calling fsck - with the filesystem to check. I don't think it's to do with inodes or block size, etc. There's about 2M inodes on /var. A manual fsck on a dirty shutdown on this partition (ignoring the problem in hand) takes a couple of minutes. Hmmm ... - If these are production boxes, I'd recommend turning it off until you resolve - the problem. Indeed, I tried that last night on one machine and it put the load through the roof(48). Yikes! Is the machine still responsive? Sometimes you can put the load that high and still have a functional box. I'm guessing by the way the conversation is going that you're able to grab one of these boxes and make some tweaks. Possibly try putting the spool directory on a dedicated partition and mounting it async? If the box shuts down dirty, you'll probably have to newfs the partition before you can use it again. At least make sure the spool partition is seperate from your log partition, that should help to mitigate the problem (although you may already have done that). - I don't know if this would qualify as advice, but since nobody else - seems to have any suggestions, I figured I'd throw my thoughts in. - Are you using ATA or SCSI drives? SCSI. - Does issuing a manual sync once you've stopped the spooling process help - any? No. I'd already tried numerous syncs, and of course a clean shutdown tries that too. I was wondering if maybe the syncs were taking longer than the shutdown process was willing to wait. - Are these all identical mobos ... possibly a BIOS update available? Haven't looked for an update, but I think they're all identical. Hmmm ... but the fact that you're using SCSI makes this less of an issue, unless it's onboard SCSI. Possibly an update to the SCSI BIOS? - These aren't IBM ATA drives are they? I had one of those give me grief for - months (if you look in the archives, you should be able to find details on - which drives caused problems). Alas not! They're straightforward Seagates, which in other machines we use (much lighter load) don't have this problem. - Have you tried updating one of the machines to 4.8 to see if the problem - has been fixed? I haven't tried that yet but will do so. I'm also going to test a 5.1R machine, perhaps the background fsck will help when I alas come to reboot. It may save you some time to look in CVS under the files for the drivers for the SCSI subsystem as well as the drivers for you specific cards to see if any commit messages talk about fixing problems like this. My experience with background fsck is that the machine is slow as hell while the background fsck is running. Whether or not this is better or worse than what you're experiencing with 4.7 is a question only you can answer. - Like I said, not good advice, just some ideas for you. All advice and ideas are welcome. Well ... I'm really shooting in the dark with these suggestions, but hopefully there will be something useful. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Softupdates: df, du, sync and fsck [quite long]
Hello, I've a couple of questions about soft updates. I've Googled heavily on this but not really found a satisfactory answer. The story: I'm running on numerous FreeBSD 4.7 SMP machines as primary MX machines. The mail is not stored on the FreeBSD machines but on NetApps via NFS. However the mail is temporarily spooled on the FreeBSD machines during normal MTA handling and passing to an anti-virus scanner. I have one large partition /var on each machine where basically all the work and temporary/transient files for the MTA and AV scanner takes place. These machines are heavily utilised, running quite hot with a load average of anything from 2 to 8. Many thousands of temporary files are thus created and deleted a minute. I have no problem with this as nearly all email is delivered in under 1 minute whatever. I notice that after a while the amount of free space as shown by df considerably varies from a du on /var. I'm aware of why this happens with soft updates, but that's not the whole story. If I turn off incoming email on a machine, the space does not seem to sync back to what it should be. No matter how long I turn off the MTA, the space is simply not returned, and df/du show differences of about 5:1. Nothing else is writing/holding open files on that partition (even turned off syslog, cron, etc. and checked using lsof). In comparison, if, for example, on my normal desktop machine I create a 500MB file, then delete it, the space shortly afterwards is returned to me when I run df. The only way I've been able to recover this space to what it should be is to reboot the machine. Which brings me to the next problem... As an example, here is a snippet from the console from when I rebooted an affected machine: boot() called on cpu#2 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...timed out syncing disks... 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 giving up on 22 buffers Uptime: 27d23h1m27s Rebooting... As you can see the file system is unable to sync. When the machine reboots it literally takes hours to fsck the /var partition (only about 15GB). And the fsck output is full of messages like this: UNEXPECTED SOFT UPDATE INCONSISTENCY Now, is there a problem here with soft updates losing track of what is going on on this busy partition? It would appear to be so as quietening the machine does not lead to a proper sync. Secondly, why does the fsck take such an inordinate amount of time for a smallish partition? I really like the performance benefits of soft updates, but it seems that I'm going to have to turn it off on /var because of the problems that eventually occur. If anyone has some advice I'd be grateful. Cheers, John. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Softupdates: df, du, sync and fsck [quite long]
John Ekins wrote: Hello, I've a couple of questions about soft updates. I've Googled heavily on this but not really found a satisfactory answer. The story: I'm running on numerous FreeBSD 4.7 SMP machines as primary MX machines. The mail is not stored on the FreeBSD machines but on NetApps via NFS. However the mail is temporarily spooled on the FreeBSD machines during normal MTA handling and passing to an anti-virus scanner. I have one large partition /var on each machine where basically all the work and temporary/transient files for the MTA and AV scanner takes place. These machines are heavily utilised, running quite hot with a load average of anything from 2 to 8. Many thousands of temporary files are thus created and deleted a minute. I have no problem with this as nearly all email is delivered in under 1 minute whatever. I notice that after a while the amount of free space as shown by df considerably varies from a du on /var. I'm aware of why this happens with soft updates, but that's not the whole story. If I turn off incoming email on a machine, the space does not seem to sync back to what it should be. No matter how long I turn off the MTA, the space is simply not returned, and df/du show differences of about 5:1. Nothing else is writing/holding open files on that partition (even turned off syslog, cron, etc. and checked using lsof). In comparison, if, for example, on my normal desktop machine I create a 500MB file, then delete it, the space shortly afterwards is returned to me when I run df. The only way I've been able to recover this space to what it should be is to reboot the machine. I don't know what's wrong, but does unmounting and remounting the partition reclaim the lost space? As an example, here is a snippet from the console from when I rebooted an affected machine: boot() called on cpu#2 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...timed out syncing disks... 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 giving up on 22 buffers Uptime: 27d23h1m27s Rebooting... As you can see the file system is unable to sync. When the machine reboots it literally takes hours to fsck the /var partition (only about 15GB). And the fsck output is full of messages like this: UNEXPECTED SOFT UPDATE INCONSISTENCY Well, this sure isn't good. Now, is there a problem here with soft updates losing track of what is going on on this busy partition? It would appear to be so as quietening the machine does not lead to a proper sync. Secondly, why does the fsck take such an inordinate amount of time for a smallish partition? If there's a LOT of inodes with problems, it could easily take a while to fix. Also, if you run fsck without specifying a filesystem to fix, it exhaustively checks all filesystems. So even if the problem is on /var, it might spend a long time checking /usr as well. You can work around this by calling fsck with the filesystem to check. I really like the performance benefits of soft updates, but it seems that I'm going to have to turn it off on /var because of the problems that eventually occur. If these are production boxes, I'd recommend turning it off until you resolve the problem. If anyone has some advice I'd be grateful. I don't know if this would qualify as advice, but since nobody else seems to have any suggestions, I figured I'd throw my thoughts in. Are you using ATA or SCSI drives? Does issuing a manual sync once you've stopped the spooling process help any? Are these all identical mobos ... possibly a BIOS update available? These aren't IBM ATA drives are they? I had one of those give me grief for months (if you look in the archives, you should be able to find details on which drives caused problems). Have you tried updating one of the machines to 4.8 to see if the problem has been fixed? Like I said, not good advice, just some ideas for you. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SoftUpdates on /
# [EMAIL PROTECTED] / 2003-02-21 14:52:45 -0500: the reason that they disabled by default on / is almost certainly because the / is usually *small*, not large. thus spoke Terry Lambert in Message-ID: [EMAIL PROTECTED]: : I believe the reason it's not on in sysinstall is that sysinstall : tries to mount things async on the initial install, so that doing : things like unpacking ports doesn't take forever. If it fails, you : can just restart, and having to do that a couple of times is still : faster than waiting for ordered metadata. : The technical reason that it doesn't do it is that the mount update : is not logically an unmount without destroying vnodes(inodes) in : core, with a remount with the new options. The main reason for : that is that the dependencies go all the way to the buffer cache, : and the backing vnode (e.g. the raw device) that's mounted does : not necessarily get its buffers flushed. Basically, you'd have to : put a little more work into the mount update code. : This was discussed a long time ago on -arch, when soft updates : first came into FreeBSD, and then again every 18 months or so, : ever after. See Kirk's postings on the subject, if you don't : want to take mine for it. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
SoftUpdates on /
Hi guys, I know that in the mailing list a while ago people were wondering why SoftUpdates were not enabled by default at install time on the / partition. Now I installed FreeBSD 4.7 RELEASE into a 4GB slice. I did not create seperate bits for / or /usr and such - but one large big space. So I enabled SoftUpdates when I was busy with FDISK at the install time and now it seems like it may have been a bad idea. Now I know 4GB is not much but it seems that there is no more space left. And at times df -h will tell me there is -180MB available on / ! [ Dont get me wrong here, I am not saying that SoftUpdates is causing me lack of space. ] Now I know that I should just du to see whats taking up the space and I will investigate that this weekend - but I was wondering if it was a bad idea to have gone and enabled SoftUpdates on / seeing as it is one big slice/partitoin? This machine is just a setup that I've got to play with - I'm sharing it with WinXP but would like to move across to FreeBSD full time. So I have no problems with having to re-install it! Kind regards, Alistair. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: SoftUpdates on /
Alistair Phillips wrote: Hi guys, I know that in the mailing list a while ago people were wondering why SoftUpdates were not enabled by default at install time on the / partition. Now I installed FreeBSD 4.7 RELEASE into a 4GB slice. I did not create seperate bits for / or /usr and such - but one large big space. So I enabled SoftUpdates when I was busy with FDISK at the install time and now it seems like it may have been a bad idea. Now I know 4GB is not much but it seems that there is no more space left. And at times df -h will tell me there is -180MB available on / ! [ Dont get me wrong here, I am not saying that SoftUpdates is causing me lack of space. ] Now I know that I should just du to see whats taking up the space and I will investigate that this weekend - but I was wondering if it was a bad idea to have gone and enabled SoftUpdates on / seeing as it is one big slice/partitoin? This machine is just a setup that I've got to play with - I'm sharing it with WinXP but would like to move across to FreeBSD full time. So I have no problems with having to re-install it! You don't have to reinstall to disable softupdates. If you read the man page for tunefs, it says that the changes will be made, but won't take effect until the system is rebooted. So you should be able to use tunefs to turn of softupdates and just reboot the machine to have it take effect. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: SoftUpdates on /
On Friday 21 February 2003 08:10 am, Alistair Phillips wrote: | Hi guys, | | So I enabled SoftUpdates when I was busy with FDISK at the install | time and now it seems like it may have been a bad idea. Now I know | 4GB is not much but it seems that there is no more space left. And | at times df -h will tell me there is -180MB available on / ! [ Dont | get me wrong here, I am | not saying that SoftUpdates is causing me lack of space. ] Softupdates don't take up any more or less space than not having them; just have too much stuff installed. Softupdates can cause *transient failures to find space, but if you still have too little space after five minutes, then softupdates has nothing to do with it. And softupdates work much *better* on large partitions than small ones; with a 4G partition the transient space loss problem is virtually non-existant; the reason that they disabled by default on / is almost certainly because the / is usually *small*, not large. -- Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: SoftUpdates on /
On Friday 21 February 2003 08:10 am, Alistair Phillips wrote: | Hi guys, | | So I enabled SoftUpdates when I was busy with FDISK at the install | time and now it seems like it may have been a bad idea. Now I know | 4GB is not much but it seems that there is no more space left. And at | times df -h will tell me there is -180MB available on / ! [ Dont get | me wrong here, I am not saying that SoftUpdates is causing me lack of | space. ] http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#SAFE-SOF TUPDATES Right from the horse's mouth so to speak as to the odd disk space results of using soft-updates. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: SoftUpdates on /
John Straiton [EMAIL PROTECTED] writes: On Friday 21 February 2003 08:10 am, Alistair Phillips wrote: | Hi guys, | | So I enabled SoftUpdates when I was busy with FDISK at the install | time and now it seems like it may have been a bad idea. Now I know | 4GB is not much but it seems that there is no more space left. And at | times df -h will tell me there is -180MB available on / ! [ Dont get | me wrong here, I am not saying that SoftUpdates is causing me lack of | space. ] http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#SAFE-SOFTUPDATES Right from the horse's mouth so to speak as to the odd disk space results of using soft-updates. A little out-of-date, even; the filesystem code has recently been adjusted to do garbage collection before reporting an out-of-space problem. [Not that this has much effect on the concerns in question.] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: softupdates on /?
On Sat, Oct 19, 2002 at 11:40:34AM +0200, Gabriel Ambuehl wrote: during the process of setting up some new servers I noticed that sysinstall will enable softupdates by default for everything BUT /. Is there any risk if I set / to use softupdates as well? The problem with softupdates is that a modification to the contents of a file system would result in a transient use of sufficient space to contain both the old and new versions of all affected files. Normally this is not a problem, but in certain cases it can lead to file modifications failing because of a full filesystem even though there is ultimately sufficient space available. One common instance of this is doing a 'make installworld' or 'make installkernel' where typical small root partitions generated by sysinstall can be overflowed. Now, arguments about how large a root partition should be or whether it should be amalgamated into /usr are neither here not there, but the contents of a standard root partition are generally static between major upgrades so there's no advantage to be gained by turning softupdates on. (Nb. This assumes that /var and /tmp are (sensibly) on different partitions to the root). It works, but I'm not sure about the possible implications of this... For general use, softupdates on the root partition is not a problem. If your root partition is big enough to let you do whatever you need to by way of updating your system despite enabling softupdates, then you can turn it on with impunity. Of course, the size of the contents of the root partition tends to grow over time, so you may have to revisit that decision later on. It's also the case that modifications have been made to softupdates that ameliorate this effect, certainly in 5-CURRENT, not sure if they've been MFC'd to -STABLE though. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re[2]: softupdates on /?
-BEGIN PGP SIGNED MESSAGE- Hello Matthew, Saturday, October 19, 2002, 1:29:47 PM, you wrote: For general use, softupdates on the root partition is not a problem. If your root partition is big enough to let you do whatever you need to by way of updating your system despite enabling softupdates, then you can turn it on with impunity. Of course, the size of the contents of the root partition tends to grow over time, so you may have to revisit that decision later on. That's exactly why I have root Partitions of about 300MB right now. Vastly over what's ever going to be needed but in the time of sub 100$ 80GB drives, this isn't of much concern to me anymore. Thanks for the explanations! Best regards, Gabriel -BEGIN PGP SIGNATURE- Version: PGP 6.0.2i iQEVAwUBPbE08cZa2WpymlDxAQHp4Af/SnyRiG6sKNZ6Bu9V6usaOkSTmTwGBOWn oqUh1TrUzJ2fzXn2CCDMEU+hV4swRroEOhnMannpQuN9hJlaEg71ABpNL8X+GSBT kcnVeC39jYCo3nBNO737huNAJ8pDKK/WB8odksQTizmzLgWQG0qUMLDqXihd2OeE U/P8CVHsYOsQBLqVcqnXQl4ykA9OjNriHkV9vZwlQIB4gkfZh5w+cnZ/wPqwJj+d 7eNcmNwLhr5kEl7i5LgiCnDsu+cDHg7G3O/bhQWDseZL2keq8mdxB51uGp8tzW3I 6c6pxz2ViAFNLK55dJOkUsDpnNyjiTB0mKXjMXOSoiuh8LXAKIdfZQ== =U4Zs -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Enabling Softupdates remotely ...
In the last episode (Jul 17), Marc G. Fournier said: I think in 5.0, there is an option to have this done on a reboot, but is there a safe way of doing this in 4.6-STABLE? Where I can have it enabled on reboot? I add a tunefs -n enable /dev/da0s1a at the very top of /etc/rc, reboot, then remove the line. Basically you can do it anywhere before root gets remounted r/w. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Force softupdates to sync? (was: Dump / soft updates interaction?)
On Monday 15 July 2002 09:52 am, Richard Tobin wrote: | Yes. You need to wait for the system to settle down before dumping. | | Is there any way to wait until a soft-update filesystem is up-to-date - | something like sync (which doesn't wait for soft updates to complete). | | Of course you can unmount and remount, but that's not always possible. As far as I know, there is not, but this is something I've wanted for a while. Better yet, I'd like a command to synchronously force a full sync of the softupdates information. Is there such a thing? Would it be conceivable to devise such a thing? Anybody have more insight than me? -- Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) http://www.babbleon.org http://www.eff.org http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
