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
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]
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: 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]
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
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
