Re: Sysinstall automatic filesystem size generation.
On Sunday 28 August 2005 11:37 pm, you wrote: I don't really understand what you're so worked up about: if you don't like the defaults, don't use them. Come on now, Dave. I know that you don't really mean this. You are not a zombie, are you? After all, 'like' is an analog, subjective term. There are various grades of likability. For example, I may like something a lot, I may like it just a bit, I may loathe it, or I may love it. I'm sure you can understand that it is not unreasonable to 'like' the default functionality, yet still see room for improvement in it. Right? In the real world, the mantra don't use, what you don't like cannot transcend boundaries, no improvements are ever made, and only a finite number of alternatives will ever be available. This is fine for some people, others make an effort to improve the situation. Of course this is much more of a philosophical issue that a technical one. I suppose I'm worked up because I am passionate about things that I really DO like - such as FreeBSD. Therefore, if I see something which I believe could use improvement, I take action to try and make that improvement happen. Although I greatly appreciate your response, I was hoping to receive a more technical perspective regarding people's thoughts on the alleged shortcoming. If your opinion is I think the current functionality is fine then so be it. Remember, I'm talking about the 'path of least resistance', I understand that I could label the slice manually with any number of different configurations. The issue I was hoping to shed some light on is... Can the auto-configuration mechanism stand to be improved?. Is it reasonable (in today's era of dirt cheap disk space) to have a mere 256MB allocated to /tmp (or /var or even /) by default? When I looked at the code, it struck me that the 'defaults' aren't so much defaults as they are maximums for the default usage. It is my opinion that the typical end-user should not need to consider the nearly infinite number of ways to configure his or her filesystems. There is a 'best-practice' recommended by experts (e.g. create /, /var, /tmp, /usr) and it presumably should suit the majority of situations encountered. One day, in the near future, a new FreeBSD user will receive a disk drive as a gift that has a capacity in the terabyte range. They will then (unwittingly) proceed to do a very typical, default installation of FreeBSD, and end up with a 256MB /tmp! I'm actually sad to hear that you think this is acceptable. In fact, I think it is this kind of attitude that keeps open-source systems from being accepted by the population at large. Does your average fireman, police officer, accountant, doctor, lawyer, etc. want to think about how they will be laying out their filesystems when the reality is that a reasonable and typical layout could be done automatically? But if you want to change it so the defaults are computed automatically, submit a PR with your patches. I really wouldn't have a problem doing this. However, before I even begin thinking about implementing something, I'd like feedback from the community to insure that my reasoning is correct. This should help maximize the utility of the patches as well as the likelyhood that they are actually imported into the tree. For example, I thought that I heard sysinstall was being completely re-written by a Google-summer-of-code sponsored project, I may just be confusing this with something else. It would be an awful waste of time to implement a change twice or to completely botch something for mere lack of knowledge (especially when there is a vast pool of human knowledge to draw from such as this mailing list) Remember, the sysinstall program is used by almost every FreeBSD user to perform an installation... it isn't a piece of code you want to simply 'hack' at. I'm sure you have heard of the stories where a missing semicolon caused a 10 million dollar rocket to explode or a vital telecom network to black-out for hours (if not days) on end. I've lived through these types of stories and it has forced me to be much less capricious when I sit down to write a piece of code. As they say... a stich in time, saves nine. -Dino *** Walter Sobchak: GOD DAMN IT! Look, just because we're bereaved, that doesn't make us saps! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Sunday 28 August 2005 11:57 pm, you wrote: For anything over a 9gb disk, I just make one big / partition. If you sub partition, you'll always end up filling one (either /var or /tmp quickly or /usr eventually) and wish you had picked different sizes. This is a very straight-forward way of doing things. Do you really think that sysinstall should use a similar method when it attempts to auto-configure a slice? From what I understand there are quite valid reasons why you would want a seperate /, /var, /tmp, and /usr. For some reason I recall being informed that more critical filesystems should reside closer to the beginning of the disk. I'm not too sure why, maybe someone would care to explain why it isn't the best practice to have a single monster /? I have simply come to accept this as fact and wouldn't mind a refresher myself. -Dino *** Maude Lebowski: What do you do for recreation? The Dude: Oh, the usual. I bowl. Drive around. The occasional acid flashback. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
C. Michailidis wrote: Remember, I'm talking about the 'path of least resistance', I understand that I could label the slice manually with any number of different configurations. The issue I was hoping to shed some light on is... Can the auto-configuration mechanism stand to be improved?. Is it reasonable (in today's era of dirt cheap disk space) to have a mere 256MB allocated to /tmp (or /var or even /) by default? The default sizes are now currently 512 MB for / and /tmp, and 1024 MB plus space for one crashdump on /var. If anything, these are vast overkill for most systems; on /, for example, it is hard to imagine a situation where a normal user would use more than 150MB of space unless they were doing something which they shouldn't be doing. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
yes, that's quite generous. why isn't /tmp just an mfs mount though? On Sun, 28 Aug 2005, Colin Percival wrote: C. Michailidis wrote: Remember, I'm talking about the 'path of least resistance', I understand that I could label the slice manually with any number of different configurations. The issue I was hoping to shed some light on is... Can the auto-configuration mechanism stand to be improved?. Is it reasonable (in today's era of dirt cheap disk space) to have a mere 256MB allocated to /tmp (or /var or even /) by default? The default sizes are now currently 512 MB for / and /tmp, and 1024 MB plus space for one crashdump on /var. If anything, these are vast overkill for most systems; on /, for example, it is hard to imagine a situation where a normal user would use more than 150MB of space unless they were doing something which they shouldn't be doing. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On 平成 17/08/29, at 12:30, C. Michailidis wrote: [...] I understand that the automatically generated values by sysinstall are the dumbest settings you can ask for... but auto-allocating a maximum of 256mb for the root, var, and tmp filesystems (even if you have an incredibly large slice in the 100's of GB) seems to be BEYOND dumb. Perhaps I've just pointed out that I am, in fact, beyond dumb, lol! ;-) Anyway, If it's simply a matter of not having enough programming resources, I'd be more than happy to make the changes to sysinstall and offer the unified diffs. Just let me know your thoughts so that the changes may be relevant for all users. I can sympathize. I've been caught by bad partition sizes. But I never take the default sizes. In particular, I check the size of /var and its sub-partitions carefully. (Seems like nobody uses / tmp that heavily anymore, but /var/tmp gets hit a lot, and /var/log may need to be relatively huge, depending on what the system is doing, etc.) A partition wizard (I hate that term, but you know what I mean.) that would coach new users and remind old users about the effects of freeBSD layout on partition sizes would, I'm sure, be welcome, if you want to take the trouble. Mind you, simple ruled apportionment would not be sufficient. We would like to have sets of rules, one for a pure web server, one for a basic home-user websurfing, e-mailing, letter-writing coffee-table-top, several for different kinds of firewalls and bridges, ... And what about older disks, where cylinder sizes, number of reported heads, etc. were meaningful? No, that's probably not relevant except for RAIDs. (As long as I'm making demands on your time, why not think big? ;^) Anyway, it could be a useful project, but you'll want to recognize there's a lot of stuff hiding under the surface there. Joel Rees [EMAIL PROTECTED] digitcom, inc. 株式会社デジコム Kobe, Japan +81-78-672-8800 ** http://www.ddcom.co.jp ** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Jon Dama wrote: yes, that's quite generous. why isn't /tmp just an mfs mount though? While I like that suggestion personally, some people get perturbed about files in /tmp going away if the power fails or you reboot. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
C. Michailidis wrote: This is a very straight-forward way of doing things. Do you really think that sysinstall should use a similar method when it attempts to auto-configure a slice? From what I understand there are quite valid reasons why you would want a seperate /, /var, /tmp, and /usr. For some reason I recall being informed that more critical filesystems should reside closer to the beginning of the disk. I'm not too sure why, maybe someone would care to explain why it isn't the best practice to have a single monster /? I have simply come to accept this as fact and wouldn't mind a refresher myself. The handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disk-organization.html) has quite a sensible discussion about this: quote Different filesystems can have different mount options. For example, with careful planning, the root filesystem can be mounted read-only, making it impossible for you to inadvertently delete or edit a critical file. Separating user-writable filesystems, such as /home, from other filesystems also allows them to be mounted nosuid; this option prevents the suid/guid bits on executables stored on the filesystem from taking effect, possibly improving security. FreeBSD automatically optimizes the layout of files on a filesystem, depending on how the filesystem is being used. So a filesystem that contains many small files that are written frequently will have a different optimization to one that contains fewer, larger files. By having one big filesystem this optimization breaks down. FreeBSD's filesystems are very robust should you lose power. However, a power loss at a critical point could still damage the structure of the filesystem. By splitting your data over multiple filesystems it is more likely that the system will still come up, making it easier for you to restore from backup as necessary. /quote In addition, there are some security implications - you cannot hard-link across filesystems (well not last time I tried anyway...). Finally, I use everything in / for my workstation, but am reconsidering after a runaway file writing process filled up everything and panicked the box - I am guessing that if I had a separate /home (say), the that would not have happened! Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 and -O2 option
Rene Ladan wrote: On Sun, Aug 28, 2005 at 04:30:19PM +0400, Boris Samorodov wrote: Hi! As for 5.x notes about -O2 (libalias, gcc) were removed at revision 1.229.2.7 of /usr/src/share/examples/etc/make.conf. But for 6.0-BETA3 we do have these warnings. Should they be removed as for 5.x? Is it safe to use -O2 to build/install kernel, world, ports fro 6.0? Kernel and world seem to be ok with -O2, for ports it is not advised. Hi, I may have missed a thread or something (just let me know :) ) - why is -O2 not advised for ports on 6.0? cheers, Beto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Um, that they may be but... I was under the impression (mistaken?) that /tmp is a directory defined under the POSIX standard and is in fact supposed to be flushed in those cases, and that /var/tmp is to be used for programs desiring persistant storage across shutdowns (scheduled and unscheduled). Perhaps it only says that a program is not allowed to rely on /tmp being persistent. I don't have a copy at hand :-/ -Jon On Mon, 29 Aug 2005, Chuck Swiger wrote: Jon Dama wrote: yes, that's quite generous. why isn't /tmp just an mfs mount though? While I like that suggestion personally, some people get perturbed about files in /tmp going away if the power fails or you reboot. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Monday 29 August 2005 02:23 am, Colin Percival wrote: The default sizes are now currently 512 MB for / and /tmp, and 1024 MB plus space for one crashdump on /var. If anything, these are vast overkill for most systems; on /, for example, it is hard to imagine a situation where a normal user would use more than 150MB of space unless they were doing something which they shouldn't be doing. Colin Percival Are you referring to 6.x? I ask only because I just cvsuped my 5-stable workstation and the file /usr/src/usr.sbin/sysinstall/label.c still shows: #define ROOT_DEFAULT_SIZE 256 #define USR_DEFAULT_SIZE3072 #define VAR_DEFAULT_SIZE256 #define TMP_DEFAULT_SIZE256 Maybe I'm not looking in the right spot? In any case, this issue is neither here nor there. I trust that these are vast overkill for most systems and I *hope* that it will continue to be the case for the foreseeable future. However, a very famous person has been haunted by a quote which has been attributed to him (even though he claims to have never said it). Do you remember 640K ought to be enough for anybody.? LOL ;-) Like I said, I thought of this after an unsuccessful portupgrade (from source) of the openoffice-1.1 port. It bombed during install, complaining that /var/tmp didn't have enough room. I began thinking... hey, I have a 60GB disk drive with plenty of free space in /usr, why are /tmp and /var only 256MB? From what you guys are telling me, I'm beginning to think that the size of my filesystems are fine, but that the latest openoffice is somehow the culprit. I thought I'd try portupgrading openoffice-1.1 from packages (they weren't available last time I had tried). Although that succeeded in downloading and installing... it exploded during runtime complaining about some missing shared object files. Honestly, I don't care too much about this matter though, I just backed 1.1.5rc2 out (after all it is just a *candidate*, and apparently a broken one). Oh, btw, thanks for the update Colin. -Dino *** The Dude: Yeah, well. The Dude abides. The Stranger: The Dude abides. I don't know about you but I take comfort in that. It's good knowin' he's out there. The Dude. Takin' 'er easy for all us sinners. Shoosh. I sure hope he makes the finals. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Sysinstall automatic filesystem size generation.
From: C. Michailidis [sysinstall FS sizing defaults] ... Isn't it safe to make some of the default sizes a wee bit larger? That is, a 256mb /tmp and /var doesn't seem appropriate if you have one of these massive modern disk drives. For christ's sake, I'd gladly give up a GB or two of /usr so I could build openoffice without needing to consider that I may need an extra few megabytes in /var at the time of the system install. ... Wouldn't it be smart to remove the hardcoded default sizes altogether and dynamically generate them according to a reasonable function? Probably, but a template for something like this isn't simple unless it's created as part of a general profile-based installer that would inform sysinstall of the machine's purpose in life. For example, a workstation or Windows replacement would need several extra GB in /usr whereas a server would get away with a much smaller /usr, but need those extra file-systems for logs, spools and other data. There are, however, some basic constants: If /usr, /var and /home are on another file-system, / doesn't need to be more than 150-200 MB. There just isn't that much in the root file-system. Assuming the default log retention and no spooling, /var will likely never grow past 50MB. Adding a mail, web, db or log server or increasing log retention will go well past that mark, but then such servers should have subordinate file-systems to handle the extra data. What comes with the OS will take less than 300MB in /usr. /usr/src and /usr/obj eat around 500 MB each. /usr/local eats around 1 GB for most servers and 3 GB on a desktop. /usr/X11R6 is empty if X isn't installed, the base Xorg server package is a few hundred MB and a desktop can need several GB. /usr/ports should have 1-2 GB just for distfiles on a desktop built from ports and 3 GB for work if you're building something huge, like KDE. I size /usr/ports to 6 GB on my desktop machines. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Monday 29 August 2005 02:51 am, you wrote: The handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disk-organization.html) has quite a sensible discussion about this: I knew that there was a reason I liked using sysinstall's automatic filesystem generation feature :-) Oh, a big TY to everyone for the timely, cordial, and quite informative responses! -Dino P.S. Hope you liked the movie quotes - if you haven't seen the movie The Big Lebowski rent it!! It had me in stitches. The Dude: Did you ever hear of The Seattle Seven? Maude Lebowski: Mmm. The Dude: That was me... and six other guys. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Mark Kirkwood wrote: FreeBSD's filesystems are very robust should you lose power. This sentence is completely bogus (or at best: wishful thinking) and should be deleted. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Monday 29 August 2005 04:24 am, you wrote: Probably, but a template for something like this isn't simple unless it's created as part of a general profile-based installer that would inform sysinstall of the machine's purpose in life. For example, a Sure, I can understand this perfectly. And I agree 99%. Ultimately the machine's purpose in life is the most important factor. However, since this can often be an intangible factor (where exactly do you draw the line between server/workstation/embeded system/etc/etc) the sysinstall process needs (perhaps) to rely on the more concrete variables in the puzzle which are available. That is, I may install FreeBSD onto a machine without initially having a specific purpose for the system. In this case, the dominant variable (in my mind) becomes, quite simply... disk size. After all, I have no specific purpose for the system, it will be a general-purpose machine and in a sense all other factors are equal. It struck me as peculiar that I could be installing to a disk over 200GB in size, indicate to sysinstall that it should layout the filesystems in its default manner... and I would actually end up with a /tmp (or /var or even /) that is 256MB (well, let's say 512MB with the new information Colin has given us). The numbers themselves don't matter in my mind, the fact that they are not a function of the disk size does. The truth is, they are related to the size of the disk (I noticed this while browsing the code for sysinstall) but they only vary if the size of the disk is *smaller* than some already small, fixed number. Effectively, we are taking a known variable that may fluctuate greatly (disk size) and completely ignoring it during installation. Pretty dumb, no? Obviously, this leaves a bad taste in my mouth. Take it to an extreme and maybe I can convert you to my team. Imagine installing to a disk that is 500 terabytes in size... wouldn't it be odd (to say the least) for sysinstall to allocate some infinitesimally small fraction of the disk to /tmp? Isn't /tmp just a place to store temporary files? Isn't there the *possibility* that you are using your system correctly and yet still want to store a large temporary file? I agree, a general profile-based installer would be ideal. Unfortunately, we live in the real world and thus it may not be practical. This fact should not preclude us from making improvements which ARE practical AND *approximate* the ideal? The first thing that came to my mind was to base the sizes on the natural logarithm function. Natual log came to my mind because the existing implementation has a ceiling, I wanted a wee bit more - since ln grows slowly I'd have the best of both worlds? The more I think about it, the more I want to say the relationship should simply be linear. Bottom line, I don't know what function would be the *best* to use, but I do believe something like this (for starters) is practical and most likely superior to the current functionality. Many people probably agree with Colin... these [values] are vast overkill for most systems - I do too, but I believe this is a subjective matter. Having a 200GB disk (IMHO) is also vast overkill for most systems. Does this mean disk manufacturers should force a user to generate valid reasons as to why they need the disk space before selling them the disk drive? The question that needs to be answered (I suppose) is: can we think of a practical, yet more reasonable way of having sysinstall allocate space for the filesystems? It's my opinion that the answer is yes. I do not find it reasonable to always recommend that the user create the same size /, /var, and /tmp no matter how incredibly large (or small) the user's disk drive is. You may agree or disagree... I just pray to God I've made myself clear at this point, lol. Just my 2 cents, Dino ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
C. Michailidis wrote: Effectively, we are taking a known variable that may fluctuate greatly (disk size) and completely ignoring it during installation. Pretty dumb, no? Obviously, this leaves a bad taste in my mouth. Take it to an extreme and maybe I can convert you to my team. Imagine installing to a disk that is 500 terabytes in size... wouldn't it be odd (to say the least) for sysinstall to allocate some infinitesimally small fraction of the disk to /tmp? Isn't /tmp just a place to store temporary files? Isn't there the *possibility* that you are using your system correctly and yet still want to store a large temporary file? From my experience, 256MB is usually more than enough for /tmp. The /tmp directory isn't typically used to store arbritrary huge datasets but is used only by system utilities, scripts, etc., for storing (small) temporary files. The /tmp directory is often a (virtual-) memory-backed filesystem, and on some systems this is the default setting (Solaris, NetBSD 2), so a developer cannot assume in any case that /tmp will be large. Furthermore, the operating system occupies only a small portion of my large hard drive in my workstation, for example. The rest is occupied by, uhm, user files. It doesn't make sense to scale up the basic filesystems by orders of magnitude relative to disk size. I do agree however, that 256mb might be a bit small for / or /var. Maybe cap those at 1GB (/) for the default settings. The /usr filesystem should be at least 5-6GB for a typical workstation setup, if space permits, but probably not more than 10GB. mkb. P.S.: Please instruct your mail program to wrap lines at about 72 characters, as is conventional. You have lines 700 characters in there, and I had to manually reformat the quoted text, which is annoying. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Matthias Buelow wrote: Mark Kirkwood wrote: FreeBSD's filesystems are very robust should you lose power. This sentence is completely bogus (or at best: wishful thinking) and should be deleted. It's probably correct if you have hw.ata.wc=0 (and are using IDE drives obviously). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Mark Kirkwood wrote: FreeBSD's filesystems are very robust should you lose power. This sentence is completely bogus (or at best: wishful thinking) and should be deleted. It's probably correct if you have hw.ata.wc=0 (and are using IDE drives obviously). I'd like to stress the probably. I've already seen unrepairable filesystem corruption with softupdates enabled in the past with good scsi disks at power loss. Furthermore, disabling the write-back cache in a typical consumer (read: typical PC workstation) environment today, with large IDE/SATA drives, is unrealistic because of the severe performance degradation, and might even be counter-indicated due to the increased weartear on the disk, which might significantly reduce the disk's lifetime. Softupdates works only in an idealized environment that doesn't match against reality. In addition, with softupdates there seems to be a much higher probability of losing files, as I have observed.. that is, getting them zero-truncated, or even deleted (which shouldn't happen in that scenario, I'm sure I've seen the results of a bug), than without. Do I still use softupdates? Yes, because of the performance benefit, but I don't treat it as much different than completely asynchronous operation, with the only difference that it's a slightly more resilient in case of a kernel crash (vs. a power outage) and I make frequent backups. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Incorrect super block--help!
Hey, newb BSDer here with a question I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root, I type: mount /dev/acd0 /cdrom and I get incorrect super block error message after a bit of CD activity, and no mount. I've tried a CD-RW I burned (the FreeBSD install disk I installed from) and an old copy of SimCity 2000, neither worked, same error message. I'm stuck. Any ideas? _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect super block--help!
You're trying to mount it as a rw disc and as a UFS file system mount -r -t cd9660 /dev/acd0 /cdrom Mark Space wrote: Hey, newb BSDer here with a question I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root, I type: mount /dev/acd0 /cdrom and I get incorrect super block error message after a bit of CD activity, and no mount. I've tried a CD-RW I burned (the FreeBSD install disk I installed from) and an old copy of SimCity 2000, neither worked, same error message. I'm stuck. Any ideas? -- __ Paul T. Root /_ \ 1977 MGB / /|| \\ ||\/ || _ | || || || \ ||__// \__/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect super block--help!
Hey, newb BSDer here with a question I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root, I type: mount /dev/acd0 /cdrom and I get incorrect super block error message after a bit of CD activity, and no mount. I've tried a CD-RW I burned (the FreeBSD install disk I installed from) and an old copy of SimCity 2000, neither worked, same error message. I'm stuck. Any ideas? The drive could have just started to fail. Sounds unlikely, but it's the kind of error you might see. Does it work with another OS, or can you substitute another drive and try that way? joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect super block--help!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Aug 29, 2005 at 10:16:54PM +1000, [EMAIL PROTECTED] wrote: Hey, newb BSDer here with a question I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root, I type: mount /dev/acd0 /cdrom and I get incorrect super block error message after a bit of CD activity, and no mount. I've tried a CD-RW I burned (the FreeBSD install disk I installed from) and an old copy of SimCity 2000, neither worked, same error message. I'm stuck. Any ideas? The real stupid question (brought on by another post that suggested using -t 9660 or whatever it is, I just use mount_cd9660) Is it shown in /etc/fstab--that is, do you have a line in /etc/fstab something like /dev/acd0 /cdrom cd9660 ro, noauto0 0 The answer is probably yes, but if not, that would be the issue and you'd need to use mount_cd9660 rather than mount. - -- Scott Robbins GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Faith: You can't trust guys. Buffy: You can trust some guys. Really, I've read about them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDEwNJ+lTVdes0Z9YRAmFwAJ4tFc0CRLiT5gcupEy5vpEqSH6l6ACfTYe9 6S4CGw7Hqz8KA7IY9c/7qaE= =AQVp -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect super block--help!
You're trying to mount it as a rw disc and as a UFS file system mount -r -t cd9660 /dev/acd0 /cdrom Mark Space wrote: Hey, newb BSDer here with a question I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root, I type: mount /dev/acd0 /cdrom Of course, this is dead right and ignore my previous response. You'll find that the cdrom drive is almost certainly in /etc/fstab as the other responder mentioned - to mount it with the default fstab options (which should work just fine): mount /cdrom The way you tried will indeed attempt to mount the device by default as a rw UFS file system. Sorry for the wrong steer. joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On 29 Aug, Matthias Buelow wrote: Mark Kirkwood wrote: FreeBSD's filesystems are very robust should you lose power. This sentence is completely bogus (or at best: wishful thinking) and should be deleted. It's probably correct if you have hw.ata.wc=0 (and are using IDE drives obviously). I'd like to stress the probably. I've already seen unrepairable filesystem corruption with softupdates enabled in the past with good scsi disks at power loss. Did you remember to disable write caching by setting the WCE mode page bit to zero? At least with SCSI, it doesn't seem to affect performance under most workloads. In addition, with softupdates there seems to be a much higher probability of losing files, as I have observed.. that is, getting them zero-truncated, or even deleted (which shouldn't happen in that scenario, I'm sure I've seen the results of a bug), than without. I've seen this when doing compile, run, panic experiments. The executable that I just compiled would end up with a size of zero after the reboot because it was still cached in RAM and executing from RAM when the machine paniced. The executable was scheduled to be written to disk about 30 seconds after it was compiled and linked, but the machine paniced before the 30 seconds was up. Softupdates only tries to guarantee that the on-disk file system is in a consistent state at all times, with the possible exception that not all space may be accounted for. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Don Lewis wrote: I'd like to stress the probably. I've already seen unrepairable filesystem corruption with softupdates enabled in the past with good scsi disks at power loss. Did you remember to disable write caching by setting the WCE mode page bit to zero? At least with SCSI, it doesn't seem to affect performance under most workloads. No.. I thought that with SCSI it is ok to leave the cache enabled because SCSI supports some sort of request queueing which doesn't break the order established by softupdates? I've seen this when doing compile, run, panic experiments. The executable that I just compiled would end up with a size of zero after the reboot because it was still cached in RAM and executing from RAM when the machine paniced. The executable was scheduled to be written to disk about 30 seconds after it was compiled and linked, but the machine paniced before the 30 seconds was up. Yes, that would account for the 0-size files but not for ones that got deleted by background fsck, with it logging UNREF FILE messages (and that were files that have definitely NOT had directory entries removed since amongst those were dot-files in my homedir, which I had to restore from backup then, and some others where I have not yet found out which they were..) Softupdates only tries to guarantee that the on-disk file system is in a consistent state at all times, with the possible exception that not all space may be accounted for. It doesn't try very hard, though, nor is it very successful. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Matthias Buelow wrote: Don Lewis wrote: [ ... ] Did you remember to disable write caching by setting the WCE mode page bit to zero? At least with SCSI, it doesn't seem to affect performance under most workloads. No.. I thought that with SCSI it is ok to leave the cache enabled because SCSI supports some sort of request queueing which doesn't break the order established by softupdates? That gives you the ability to sequence events, yes, but it doesn't mean that data which has been cached by the drive and not yet written out is fine if the power goes away. Good SCSI/RAID controllers have a small battery backup inside the computer case to address exactly this: aac0: Dell PERC 3/Di mem 0xf000-0xf7ff irq 31 at device 2.1 on pci2 aac0: i960RX 100MHz, 118MB cache memory, optional battery present aac0: Kernel 2.5-0, Build 2991, S/N x That cache will get flushed to disk even if the OS goes bonkers or disappears entirely due to no power. Maybe something like this would make you happier: # cat /etc/sysctl.conf kern.filedelay=7 kern.dirdelay=6 kern.metadelay=5 ...? Softupdates only tries to guarantee that the on-disk file system is in a consistent state at all times, with the possible exception that not all space may be accounted for. It doesn't try very hard, though, nor is it very successful. Look, there is a tradeoff between price/performance/quality (or reliability) in most circumstances. If you want more reliability, pay more to get good hardware, or accept that there will be performance loss if/when you choose to maximize reliability. It's also true that FreeBSD could do a better job or otherwise be improved. You don't have to argue that point, we're already convinced. Submitting improvements is useful. Would changing the sysctls above to shorter defaults be a good idea? -- -Chuck PS: Haven't we had this conversation before? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.0-BETA3 nfs mount of 5.3 hangs
Since I upgraded my laptop from 5.3 to 6.0-BETA3 it's doing a lot of hangs on NFS in both directions. Anyone else noticing this ? The laptop is OK when running a 5.3 partition. I'm running AMD on all hosts. I'm about to run mergemaster -sicv to upgrade my /etc from 5.3 to 6.0-BETA3, meanwhile ... ps -laxww | grep nfs 049 0 0 8 0 0 8 - SL??0:00.00 [nfsiod 0] 050 0 2 8 0 0 8 - IL??0:00.00 [nfsiod 1] 051 0 2 8 0 0 8 - IL??0:00.00 [nfsiod 2] 052 0 2 8 0 0 8 - IL??0:00.00 [nfsiod 3] 0 580 1 147 114 0 1344 1012 select Is??0:00.06 nfsd: master (nfsd) 0 582 580 0 4 0 1252 844 - I ??0:00.01 nfsd: server (nfsd) 0 583 580 104 4 0 1252 844 - I ??0:00.00 nfsd: server (nfsd) 0 584 580 104 4 0 1252 844 - I ??0:00.00 nfsd: server (nfsd) 0 585 580 147 4 0 1252 844 - I ??0:00.00 nfsd: server (nfsd) -- Julian Stacey Muenchner Unix Urlaubs Vertretung http://berklix.com Mail Ascii not HTML. Ihr Rauch = mein allergischer Kopfschmerzen. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On 29 Aug, Matthias Buelow wrote: Don Lewis wrote: I'd like to stress the probably. I've already seen unrepairable filesystem corruption with softupdates enabled in the past with good scsi disks at power loss. Did you remember to disable write caching by setting the WCE mode page bit to zero? At least with SCSI, it doesn't seem to affect performance under most workloads. No.. I thought that with SCSI it is ok to leave the cache enabled because SCSI supports some sort of request queueing which doesn't break the order established by softupdates? If WCE is set to 1, the drive immediately acknowledges writes. If WCE is set to 0 and the OS is doing tagged command queuing, the drive won't tell the OS that the write is complete until the data hits the platter, but a typical drive could have up to about 64 outstanding writes (or some combination of reads and writes) that it is free to re-order as it sees fit in order to increase performance. The key is that WCE must be set to 0 so that softupdates knows when each of the writes that it has queued to the drive has completed so that softupdates doesn't queue up any writes that depend on the previously queued writes before those older writes have reached stable storage. If WCE is set to 1, the dependent writes could reach the platter too early and the earlier writes that the later writes depend on could be lost from the drive's cache because of a power failure, which would put the file system into an inconsistent state. I've seen this when doing compile, run, panic experiments. The executable that I just compiled would end up with a size of zero after the reboot because it was still cached in RAM and executing from RAM when the machine paniced. The executable was scheduled to be written to disk about 30 seconds after it was compiled and linked, but the machine paniced before the 30 seconds was up. Yes, that would account for the 0-size files but not for ones that got deleted by background fsck, with it logging UNREF FILE messages (and that were files that have definitely NOT had directory entries removed since amongst those were dot-files in my homedir, which I had to restore from backup then, and some others where I have not yet found out which they were..) I believe I've seen UNREF'ed files, but they always seem to be compiler temporaries, etc. I've never lost any files that I haven't recently touched. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.0-BETA3 Available
[ Sorry - I could have sworn I sent this earlier... ] Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA3. This BETA includes a full set of packages for amd64 and i386 architectures. Alpha has no packages, sparc64 has everything except for KDE and Gnome. The FTP install trees are available. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues Other than the items listed in the todo list there are no known issues with this BETA. Availability The BETA3 ISOs are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html The MD5s are: MD5 (6.0-BETA3-alpha-bootonly.iso) = 7c07c44ff946657440c981455872bab5 MD5 (6.0-BETA3-alpha-disc1.iso) = bf92a2acaa622d23ae6a2f422d34d5ed MD5 (6.0-BETA3-amd64-bootonly.iso) = 45334997ac1ee50dd57be1c439fd1122 MD5 (6.0-BETA3-amd64-disc1.iso) = 7d566188eb66b7588a4ded72d55251c6 MD5 (6.0-BETA3-amd64-disc2.iso) = 84d68c5a90b9eff57ca19d3109966fac MD5 (6.0-BETA3-i386-bootonly.iso) = a917645b25f6d1661cf4e4a030d12eb5 MD5 (6.0-BETA3-i386-disc1.iso) = 1051a03b5d8c43baef907d92147fac9c MD5 (6.0-BETA3-i386-disc2.iso) = f203a81690224ffa7d727fc7b27d5f40 MD5 (6.0-BETA3-ia64-bootonly.iso) = 0986d84103b1d2b51ba988fe50dc8133 MD5 (6.0-BETA3-ia64-disc1.iso) = 05e43d428c94e7dfc2cc00c1e8fb063f MD5 (6.0-BETA3-ia64-livefs.iso) = 2b21241804cff376dce72e2ac7d262cd MD5 (6.0-BETA3-pc98-disc1.iso) = b5b8ff7b8fa3b8cdd38046e23cd272d6 MD5 (6.0-BETA3-powerpc-disc1.iso) = ef468b6843fcd8b06818a5a4d246b09f MD5 (6.0-BETA3-sparc64-bootonly.iso) = 5b27730bc310b7fea5d306f23d069c24 MD5 (6.0-BETA3-sparc64-disc1.iso) = 69eab8d48435de2a5448f7e64e984c43 MD5 (6.0-BETA3-sparc64-disc2.iso) = 64401437f91b1c086e3518ee2ff90a8f -ken pgpNAlANnCH4c.pgp Description: PGP signature
Re: Sysinstall automatic filesystem size generation.
Chuck Swiger wrote: PS: Haven't we had this conversation before? Yes, indeed, and I don't want to reopen that issue since that would lead to no new insights (and since I don't have the time atm. to contribute anything I couldn't provide any stuff myself). I was just refuting the claim of very robust filesystem when power goes out in the context of 200GB consumer-grade hardware that this thread was talking about. I think until a satisfactory solution can be found (by making softupdates and/or a journalled filesystem as reliable as possible through mechanisms like write-request barriers and appropriate flushing at these) users who're running FreeBSD on end-consumer hardware (desktop PC as workstation or personal server) should be warned that softupdates does NOT work as described on their hardware and that the filesystem can easily be corrupted when the power goes out, no matter if softupdates is enabled or not. One often sees the softupdates argument being fielded by FreeBSD advocates, typically against Linux users with journalled fs, on web forums, usenet and other less authoritative (and knowledgable) places of discussion, and it is often presented as if it were some kind of magic bullet that makes filesystem corruption impossible. This simply is not so. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Matthias Buelow wrote: Chuck Swiger wrote: PS: Haven't we had this conversation before? Yes, indeed, and I don't want to reopen that issue since that would lead to no new insights (and since I don't have the time atm. to contribute anything I couldn't provide any stuff myself). Yet you seem willing to spend time discussing the matter...? I was just refuting the claim of very robust filesystem when power goes out in the context of 200GB consumer-grade hardware that this thread was talking about. Most of the time, a FreeBSD system will come back up without losing data older than about thirty seconds, and that is tunable. Have you even tried to change the syncer sysctls I mentioned? I think until a satisfactory solution can be found (by making softupdates and/or a journalled filesystem as reliable as possible through mechanisms like write-request barriers and appropriate flushing at these) users who're running FreeBSD on end-consumer hardware (desktop PC as workstation or personal server) should be warned that softupdates does NOT work as described on their hardware and that the filesystem can easily be corrupted when the power goes out, no matter if softupdates is enabled or not. Great. I think man ata already says exactly this: hw.ata.wc set to 1 to enable Write Caching, 0 to disable (default is enabled). WARNING: can cause data loss on power failures. If your hard drive no longer works correctly when write-caching is disabled, it's defective. Nothing FreeBSD or any other system can do is going to change that. One often sees the softupdates argument being fielded by FreeBSD advocates, typically against Linux users with journalled fs, on web forums, usenet and other less authoritative (and knowledgable) places of discussion, and it is often presented as if it were some kind of magic bullet that makes filesystem corruption impossible. Often? Strawman test: can you point out 3 examples by message-id or URL? And if you prefer to run a journalled filesystem under Linux instead of softupdates under FreeBSD, by all means, do whatever makes you happy. This simply is not so. Very good. -- -Chuck PS: I don't want a thread to end on a negative note. It would be useful if FreeBSD had a more adaptable method for dealing with drive power management and caching; in particular, for laptops it might be nice to cache data for much longer-- perhaps even hours-- if nothing fsync()s, in order to permit the drive to spin down. (This is something both Windows and MacOS X are learning to do pretty well.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Chuck Swiger wrote: Matthias Buelow wrote: Chuck Swiger wrote: PS: Haven't we had this conversation before? Yes, indeed, and I don't want to reopen that issue since that would lead to no new insights (and since I don't have the time atm. to contribute anything I couldn't provide any stuff myself). Yet you seem willing to spend time discussing the matter...? Chuck, Matthias went on to say in a very simple manner by he thought a quick note was warranted. You don't agree. Why don't the two of you talk about it in private email? Matthias is right. It's been hashed out on the lists multiple times and neither side is willing to change. At this point, it's become a Did to! Did not! Did to argument between children. So like good children, go to your rooms and don't bother Mommy... John -- John T. FarmerOwner CTOGoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, Development of Networks Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
J. T. Farmer wrote: Chuck Swiger wrote: Matthias Buelow wrote: Yes, indeed, and I don't want to reopen that issue since that would lead to no new insights (and since I don't have the time atm. to contribute anything I couldn't provide any stuff myself). Yet you seem willing to spend time discussing the matter...? Matthias went on to say in a very simple manner by he thought a quick note was warranted. You don't agree. I think this matter is documented now. I think it could be documented elsewhere or in more detail if someone wanted to do so, but that involves someone pointing to a specific manpage or section of the handbook, and submitting language. The people on freebsd-doc can help, deal with mdoc or Docbook formatting, etc. Why don't the two of you talk about it in private email? I am willing to end the discussion if there is nothing productive to say. Matthias is right. Matthias is right about what? My goodness, you also are aware of people talking about softupdates in comparison to journalled filesystems often? It's been hashed out on the lists multiple times and neither side is willing to change. I've suggested a change to the sysctl's governing the syncer's timing, which ought to have a noticable impact on the issues Matthias has brought up. Feedback is welcome. (I generally am happy to look into changes and see if they are improvements.) At this point, it's become a Did to! Did not! Did to argument between children. So like good children, go to your rooms and don't bother Mommy... You're awarded -1 karma for the patronizing tone. Feel free to read other threads if you don't like what I have to say. -- -Chuck PS: Please refrain from stating my position for me, JT. I'd be happier if you quoted what I said and disagreed honestly with it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Chuck Swiger wrote: Yet you seem willing to spend time discussing the matter...? Because it's somewhat of my pet peeve and I always see the mantra-like repetition of the argument that you have to disable the write-back cache if you want any safety at all, which is a) extremely disadvantageous with today's IDE/SATA drives and hardly feasible in reality, and b) other systems like Windows and Linux can operate much safer with the cache _enabled_, on most drives except the most pathetic ones which are totally broken. One often sees the softupdates argument being fielded by FreeBSD advocates, typically against Linux users with journalled fs, on web forums, usenet and other less authoritative (and knowledgable) places of discussion, and it is often presented as if it were some kind of magic bullet that makes filesystem corruption impossible. Often? Strawman test: can you point out 3 examples by message-id or URL? A Google search finds them quickly: http://www.heise.de/ix/foren/go.shtml?read=1msg_id=7335045forum_id=70615 (german, argument is that softupdates is at least a match for a journalled fs), http://lists.freebsd.org/pipermail/freebsd-questions/2003-June/009967.html (FS + SoftUpdates is much better than journaling!) http://aussatz.antville.org/topics/HowTos/ (german, argument is 1. practically nothing can break when power goes out, and even that you can switch off the machine without any problems, except for losing the files that have been written to in the last seconds. Of course no mentioning of disk cache or any sophistication whatever.) And if you prefer to run a journalled filesystem under Linux instead of softupdates under FreeBSD, by all means, do whatever makes you happy. I don't want to do that (that is, I do want that, of course, if I'm using Linux, but in general I don't care about Linux). The point is, that both Windows and recent Linux make great effort to ensure filesystem correctness by using request barriers and clever flushing, or even complete disabling/reenabling of the cache at these barrier points, even on consumer-grade hardware. While with FreeBSD, the attitude generally seems to be a snobby here's a dime, kid, go buy yourself a real computer. That might work for server hardware but for the typical PC, which is a commodity product, and where one often cannot even select the hardware (be it because your employer puts the machine in your office, or you just order some machine somewhere because tinkering with components until a PC works flawlessly has become a royal PITA and waste of time) and so the operating system generally has to work with normal off-the-shelf hardware, which means, cheap IDE/SATA stuff, and not a super-expensive battery-backed U320 SCSI-RAID with a gratis golden Rolex and 1-year free membership in the Dubai Nad al-Sheba golf club. PS: I don't want a thread to end on a negative note. It would be useful if FreeBSD had a more adaptable method for dealing with drive power management and caching; in particular, for laptops it might be nice to cache data for much longer-- perhaps even hours-- if nothing fsync()s, in order to permit the drive to spin down. My notebook lies to me everytime when the battery is going to be out of juice soon (one of the reason I experience powerouts frequently, when I don't pay attention), so that seems to be somewhat unreliable to me.. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Matthias Buelow wrote: Chuck Swiger wrote: Yet you seem willing to spend time discussing the matter...? Because it's somewhat of my pet peeve and I always see the mantra-like repetition of the argument that you have to disable the write-back cache if you want any safety at all, No, there are other possible solutions which have been mentioned. I reiterate my question: have you tried adjusting the syncer sysctl's and seeing whether FreeBSD is more stable in the event of a power failure? [ ... ] One often sees the softupdates argument being fielded by FreeBSD advocates, typically against Linux users with journalled fs, on web forums, usenet and other less authoritative (and knowledgable) places of discussion, and it is often presented as if it were some kind of magic bullet that makes filesystem corruption impossible. Often? Strawman test: can you point out 3 examples by message-id or URL? A Google search finds them quickly: http://www.heise.de/ix/foren/go.shtml?read=1msg_id=7335045forum_id=70615 (german, argument is that softupdates is at least a match for a journalled fs), http://lists.freebsd.org/pipermail/freebsd-questions/2003-June/009967.html (FS + SoftUpdates is much better than journaling!) http://aussatz.antville.org/topics/HowTos/ (german, argument is 1. practically nothing can break when power goes out, and even that you can switch off the machine without any problems, except for losing the files that have been written to in the last seconds. Of course no mentioning of disk cache or any sophistication whatever.) Conclusion: if you're looking for unbridled FreeBSD advocacy on these lists or in the FreeBSD documentation, you've found very little. A one-line post from 2003: gosh, someone expressed a strong opinion, and even that was promptly followed up with: FFS+SU does have the disadvantages that a full fsck is still needed (run in the background), and you risk losing the last `sysctl kern.metadelay` seconds worth of files written just before a crash. ...by Dan Nelson. I'm going to skip the rest of the monologue and the Dubai Nad al-Sheba golf club as well, but thanks anyway. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcap and gig speeds.
In the last episode (Aug 26), Jason said: We are planning on updating a number of old machines, being used as IDS sensors, and in the past, there has been a known issue regarding gig speeds and pcap with regards to snort. Do you have an URL referring to the issue? As long as your pcap buffers are big enough and your machine can handle snort's CPU load I don't see a problem. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Chuck Swiger wrote: I reiterate my question: have you tried adjusting the syncer sysctl's and seeing whether FreeBSD is more stable in the event of a power failure? No, simply because I have no machine at the moment for experimenting if it takes longer until it eats its filesystem. Besides, as I have said, it is not an acute problem for me at the moment and I was merely pointing out the inadequacy of talking about robust filesystems in the context of softupdates and end-consumer harddrives. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Matthias Buelow wrote: (snippage...) I was merely pointing out the inadequacy of talking about robust filesystems in the context of softupdates and end-consumer harddrives. Would you be happy if the handbook section added a caution, or referred to the section that discusses the write cache? (FWIW - I have seen Linux + ext3 systems destroyed by power failure because the admins refused to disable write caching on ATA drives - Neither journelling or softupdates is much help if the HW is kidding you about write acknowledgment). Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Tue, 30 Aug 2005, Mark Kirkwood wrote: (FWIW - I have seen Linux + ext3 systems destroyed by power failure because the admins refused to disable write caching on ATA drives - Neither journelling or softupdates is much help if the HW is kidding you about write acknowledgment). This would certainly be case with 2.4 kernels and early 2.6 kernels. Afaik, they only made a decent attempt at solving this problem relatively recently. Ironically, phk backed out the underlying support for this safety fix from the FreeBSD kernel b.c. it wasn't integrated into the softupdates code whereas in reality the proper course of action would have been to hook it in. :-/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 and -O2 option
Kernel and world seem to be ok with -O2, for ports it is not advised. Hi, I may have missed a thread or something (just let me know :) ) - why is -O2 not advised for ports on 6.0? cheers, Beto Simply because not every port works with -O2 optimisations. It caused bad code in some circumstances. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Mark Kirkwood wrote: Would you be happy if the handbook section added a caution, or referred to the section that discusses the write cache? Yes, that would inform the user. (FWIW - I have seen Linux + ext3 systems destroyed by power failure because the admins refused to disable write caching on ATA drives - Neither journelling or softupdates is much help if the HW is kidding you about write acknowledgment). From what I understand from googling around on that issue, the write-barrier stuff should make that much more unlikely. Of course there could be the situation that it was a kernel that did not (properly) support write-barriers yet, or the Linux implementation has/had bugs (not too unlikely), or the disk was so broken that even the flushing workaround strategies were ignored or it otherwise didn't properly flush it, etc. But they're at least trying to cope with the issue. BTW., when have you last seen a broken NTFS? While I don't do Windows much, I have had quite a few crashes on Windows (2000, XP) over the years on various machines, and I always asked myself how it could be that the system is up almost immediately (probably due to log replay) with no discernible filesystem damage. Windows (NT) has been doing the write barrier flush tricks (disabling-/ reenabling the cache for flushing it) for longer than Linux and I would think that this contributes to the fault resilience of NTFS. Not that I would imply that NTFS can't be corrupted, of course. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Jon Dama wrote: Ironically, phk backed out the underlying support for this safety fix from the FreeBSD kernel b.c. it wasn't integrated into the softupdates code whereas in reality the proper course of action would have been to hook it in. :-/ Can it be put into softupdates at all? From what I understand (which is probably a rather sketchy idea of the matter), write barriers work because they are only used here to separate journal writes from data writes (i.e., to make sure the log is written, by flushing the cache, before any filesystem data hits the platters). I've read the softupdates paper some time ago and haven't found similar sequence points where one could insert such flushing. One would have to flush all the time, either continuously or in very short intervals, in order to keep the ordering, which then would amount to the same effects as if one simply disabled the cache. But probably I'm wrong here (I hope). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Tue, 2005-08-30 at 03:11 +0200, Matthias Buelow wrote: BTW., when have you last seen a broken NTFS? While I don't do Windows much, I have had quite a few crashes on Windows (2000, XP) over the years on various machines, and I always asked myself how it could be that the system is up almost immediately (probably due to log replay) with no discernible filesystem damage. Windows (NT) has been doing the write barrier flush tricks (disabling-/ reenabling the cache for flushing it) for longer than Linux and I would think that this contributes to the fault resilience of NTFS. Not that I would imply that NTFS can't be corrupted, of course. Funny you should mention it, but the last time I saw a broken NTFS was back in July. It was a friend's Windows 2000 system. The net effect was that the system would not boot fully; was not responsive to the repair option; and wouldn't allow the recovery console to start. In the end, a wipe and reinstall was necessary. Oddly enough, trying to mount the NTFS file system via a Knoppix CD before resorting to that yielded complaints about the journal being corrupted. I guess I must be lucky because I've never yet had a corrupted file system with softupdates enabled due to power loss or panic under FreeBSD (though I've experienced plenty of power losses due to the flaky power here and panics due to tracking CURRENT on my desktop system:). By reading your regular dire warnings on the subject, my experience must differ greatly from yours. ;-) BTW, if you consider softupdates fundamentally broken wrt data integrity, why don't you post your concerns to -current or -hackers, say? Surely the developers to address the problem are more likely to be found reading there? Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Matthias Buelow wrote: From what I understand from googling around on that issue, the write-barrier stuff should make that much more unlikely. Of course there could be the situation that it was a kernel that did not (properly) support write-barriers yet, or the Linux implementation has/had bugs (not too unlikely), or the disk was so broken that even the flushing workaround strategies were ignored or it otherwise didn't properly flush it, etc. But they're at least trying to cope with the issue. BTW., when have you last seen a broken NTFS? LOL, well quite often - nt4 seemed to specialize in this, win2k and winxp (particularly 2k) however, seem much better... While I don't do Windows much, I have had quite a few crashes on Windows (2000, XP) over the years on various machines, and I always asked myself how it could be that the system is up almost immediately (probably due to log replay) with no discernible filesystem damage. Windows (NT) has been doing the write barrier flush tricks (disabling-/ reenabling the cache for flushing it) for longer than Linux and I would think that this contributes to the fault resilience of NTFS. Not that I would imply that NTFS can't be corrupted, of course. But otherwise, thanks for a very informative post. Hmm, I think OSX does something like this too. Funnily enough, I have never lost files while using FreeBSD, even tho I'm using ATA disks with the write cache enabled - and I have had power loss situations. The robustness was one of the things that persuaded me to switch from (Redhat 7.3/8.0 I think) to FreeBSD (4.6 I think). However that is ancient history, If everyone is working out how to manipulate the write cache on-demand, then I guess FreeBSD needs to as well...(not volunteering... probably a bit out of my league). Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Well, I think one issue is that it destroys one of the fundamental advantages of softupdates which was that you could interleave streams of strongly ordered metadata writes without demanding a sequence for the streams collectively. By using request barriers, you are effectively forcing an additional synchronization requirement, the secret will be not forcing us all the way back to having effectively synchronous metadata writes (see below). As I understand, metadata operations are only added to the WORKLIST when their dependents have already been completed i.e., at the lowest level have had biodone called to mark the write operation completed. I am not sure how ffs_softdeps checks this property. It seems you need to add a layer of indirection. (owing to biodone being called merely when the drive has cached the request). What you know is that those operations marked completed by biodone are in fact done only after a (costly) flush cache operation is executed. Therefore you want to delay this operation for as long as possible, in fact until you actually depend on biodone being honest. I.e., at the time another operation is inserted into the WORKLIST. The secret I think is to keep track of which bp's marked B_DONE by biodone that have been certified by a flush cache. Thus permitting you to avoid some cache flushes. Furthermore, the softdep code has to be responsible for envoking the flush cache operation when it notices that the B_DONE flag that it cares about does not have a matching B_REALLY_DONE flag, which every block should have that had B_DONE set before the flush cache operation happened. I do not really know how GEOM has changed this situation. biodone seems to have been stripped of much of its old responsibilities? -Jon I'd guess that it belongs On Tue, 30 Aug 2005, Matthias Buelow wrote: Jon Dama wrote: Ironically, phk backed out the underlying support for this safety fix from the FreeBSD kernel b.c. it wasn't integrated into the softupdates code whereas in reality the proper course of action would have been to hook it in. :-/ Can it be put into softupdates at all? From what I understand (which is probably a rather sketchy idea of the matter), write barriers work because they are only used here to separate journal writes from data writes (i.e., to make sure the log is written, by flushing the cache, before any filesystem data hits the platters). I've read the softupdates paper some time ago and haven't found similar sequence points where one could insert such flushing. One would have to flush all the time, either continuously or in very short intervals, in order to keep the ordering, which then would amount to the same effects as if one simply disabled the cache. But probably I'm wrong here (I hope). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On 30 Aug, Matthias Buelow wrote: Jon Dama wrote: Ironically, phk backed out the underlying support for this safety fix from the FreeBSD kernel b.c. it wasn't integrated into the softupdates code whereas in reality the proper course of action would have been to hook it in. :-/ Can it be put into softupdates at all? From what I understand (which is probably a rather sketchy idea of the matter), write barriers work because they are only used here to separate journal writes from data writes (i.e., to make sure the log is written, by flushing the cache, before any filesystem data hits the platters). I've read the softupdates paper some time ago and haven't found similar sequence points where one could insert such flushing. One would have to flush all the time, either continuously or in very short intervals, in order to keep the ordering, which then would amount to the same effects as if one simply disabled the cache. But probably I'm wrong here (I hope). Performance might be bad, but it is still likely to be better than totally disabling write caching. For instance if you had two different write transaction pairs, where write B depends on write A, and write D depends on write C, you could issue writes A and C, flush the drive's write cache, and then issue writes B and D. You could also optimize large sequential writes by writing all the data blocks, flushing the write cache, and then updating the inode and bitmap blocks. Grouping writes to minimize the number of flushes might help performance. The key is that the drive's write cache needs to be flushed before doing a write that depends on an earlier write. The complication is that softupdates tosses the information about a write as soon as the drive acknowledges it, but if write caching is enabled, softupdates would need to retain this information until the drive's write cache is flushed. I think you could still get file system corruption on power failure if you are using ATA drives, because most high capacity drives write a track at a time, in many cases re-writing data that was last touched in the distant past. If the power fails part way through a track rewrite, then the old data on that track may be lost. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On 29 Aug, Jon Dama wrote: It seems you need to add a layer of indirection. (owing to biodone being called merely when the drive has cached the request). What you know is that those operations marked completed by biodone are in fact done only after a (costly) flush cache operation is executed. Therefore you want to delay this operation for as long as possible, in fact until you actually depend on biodone being honest. I.e., at the time another operation is inserted into the WORKLIST. The secret I think is to keep track of which bp's marked B_DONE by biodone that have been certified by a flush cache. Thus permitting you to avoid some cache flushes. Furthermore, the softdep code has to be responsible for envoking the flush cache operation when it notices that the B_DONE flag that it cares about does not have a matching B_REALLY_DONE flag, which every block should have that had B_DONE set before the flush cache operation happened. I believe you are correct. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE cpufreq hotter than est from ports
Tijl Coosemans wrote: A couple days ago I updated my system and was excited to see cpufreq and powerd in 5-stable. Since then however I noticed that my laptop temperature is about 5°C higher than with est and estctrl. I found that cpufreq when setting 200MHz for example set the absolute frequency to 1600MHz (max for this laptop) and the relative frequency (p4tcc) to 12.5% instead of using a more power conserving setting like 800MHz/25%. A variant of your patch has been committed and will be MFCd. Thanks! So, I've worked out a patch (attached) that makes sure that a lower frequency level has at most the same absolute setting (preferably less of course). This eliminates quite a few levels so somebody with a better knowledge of cpufreq should check if this patch really does something good. This is the first time I've taken a look at FreeBSD source code by the way. I added back the check for CPUFREQ_CMP since you don't want duplicate levels. This is not currently a problem with est/p4tcc but other combinations of settings could have produced duplicates with the patch's approach. Also, somewhat related, the p4tcc driver doesn't recognise acpi_throttle, which means that when you load the cpufreq module after booting, the freq levels are messed up. I'm not sure what the best solution for this is. Let p4tcc detect acpi_throttle and don't attach if it's present (like acpi_throttle does now if it finds p4tcc) or detach it before attaching? Or maybe p4tcc and acpi_throttle should be merged into one driver? acpi_throttle is only the same as p4tcc on x86 platforms. We need a better negotiation strategy in general between the different drivers. The logic for these two is already p4tcc acpi_throttle but we need to support reprobing when cpufreq.ko is loaded after boot by detaching both and then allowing p4tcc to win the probe. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
