firefox: after update - version 23: can not swap tabs
After the last major update of www/firefox to version 23 firefox rejects of moving/swapping the tabs. They are static now. I do not know whether this has to do with the great pixman update, because coincidentally I made bot the pixman update and the update of firefox towards revision 23 slipped in. My ports system and the ports are kept up to day on a almost every-two-day basis or at least weekly. The underlying OS is now FreeBSD 11.0-CURRENT #1 r256384: Sat Oct 12 18:34:38 CEST 2013 amd64. The question is: is this a kind of miscompilation or has there something minor changed and I didn't noticed that? User error? If some has a tip or hint, I'll appreciate it. Please CC me, I do not subscribe this list. Regards, Oliver signature.asc Description: PGP signature
Re: firefox: after update - version 23: can not swap tabs
El día Monday, October 14, 2013 a las 08:54:56AM +0200, O. Hartmann escribió: After the last major update of www/firefox to version 23 firefox rejects of moving/swapping the tabs. They are static now. I do not know whether this has to do with the great pixman update, because coincidentally I made bot the pixman update and the update of firefox towards revision 23 slipped in. My ports system and the ports are kept up to day on a almost every-two-day basis or at least weekly. Hello, I have a 10-CURRENT r255948 from October 1st, with all ports from head too, rev. r328930. FF is version 24.0 in the r328930 ports and the tabs can be moved fine with drag and drop. HIH matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: Reinstall without reformat
On Mon, Oct 14, 2013 at 1:21 AM, Polytropon free...@edvax.de wrote: On Sun, 13 Oct 2013 23:01:02 -0600 (MDT), Warren Block wrote: On Mon, 14 Oct 2013, Polytropon wrote: On Sun, 13 Oct 2013 13:24:30 -0400, Kenta Suzumoto wrote: Hi all. Is it possible to install FreeBSD without formatting the disk? Yes. The installer supports not formatting existing partitions. The file system characteristica will be kept, possible content will overwritten. Note that superfluous content will also be kept, except of course you previously remove everything. sysinstall supported that, but AFAIK bsdinstall does not. Oh, seems you're right. I've checked The FreeBSD Handbook for the relevant instructions for using bsdinstall at http://www.freebsd.org/doc/handbook/bsdinstall-partitioning.html and http://www.freebsd.org/doc/handbook/bsdinstall-final-warning.html and I didn't find an option to _not_ initialize existing partitions, even though it seems you can assign existing partitions without any problem. The remaining question: Will they be initialized again? I know that sysinstall had the option newfs toggle so you could skip the newfs step after you had assigned the existing partitions to the desired mountpoints. It can be seen at http://www.freebsd.org/doc/handbook/install-steps.html in Fig. 3.19 and 3.24. I have to admit that I didn't assume such a significant loss of functionality (that sysinstall provided!) in the new installer... :-( That's why maybe manually extracting the distribution files from the installation media, using the CLI tools, would probably the easiest thing: Manually mount existing partitions as desired, then extract the installation datasets, and apply any further modifications as needed. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... OR Disconnect power line of existing HDD to be reinstalled . Attach another HDD or drive , for example USB stick . Perform a fresh install on the new unit . After verifying that the new install is working properly , Shutdown the computer , attach power of previous HDD , mount it , copy all of the new files from freshly installed unit into previous HDD, Shutdown the computer , Disconnect newly installed unit , Restart the computer . It is very likely that your previous HDD will work as like newly installed . OR Do the reverse : From previous HDD , copy all of the required files to the new HDD . Disconnect previous HDD or unit . Continue with the new HDD or unit . If the previous HDD is not bootable , it is necessary to continue with the new HDD . I am applying the second kind of steps for all my new installs . In that way nothing is broken , even there is no back up of the files because nothing applied to the existing HDD . The cost of this operation is to have a spare disk or a USB stick having sufficient capacity . Personally I am not using USB sticks for such operations because they may fail unexpectedly . Thank you very much . Mehmet Erol Sanliturk ___ 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: firefox: after update - version 23: can not swap tabs
On Mon, 14 Oct 2013 09:50:48 +0200 Matthias Apitz g...@unixarea.de wrote: El día Monday, October 14, 2013 a las 08:54:56AM +0200, O. Hartmann escribió: After the last major update of www/firefox to version 23 firefox rejects of moving/swapping the tabs. They are static now. I do not know whether this has to do with the great pixman update, because coincidentally I made bot the pixman update and the update of firefox towards revision 23 slipped in. My ports system and the ports are kept up to day on a almost every-two-day basis or at least weekly. Hello, I have a 10-CURRENT r255948 from October 1st, with all ports from head too, rev. r328930. FF is version 24.0 in the r328930 ports and the tabs can be moved fine with drag and drop. HIH matthias Sorry, FF is in my case 24, too: pkg info firefox firefox-24.0,1 Have you done updating the ports regarding 20130929 in /usr/ports/UPDATING? I did on all boxes and on all boxes I did the tab-stickyness is present. My ports tree is Revision: 330274, my OS is as reported above. signature.asc Description: PGP signature
Re: firefox: after update - version 23: can not swap tabs
El día Monday, October 14, 2013 a las 10:23:49AM +0200, O. Hartmann escribió: I have a 10-CURRENT r255948 from October 1st, with all ports from head too, rev. r328930. FF is version 24.0 in the r328930 ports and the tabs can be moved fine with drag and drop. HIH matthias Sorry, FF is in my case 24, too: pkg info firefox firefox-24.0,1 root@aurora:~ # pkg_info | fgrep firefox firefox-24.0,1 Web browser based on the browser portion of Mozilla Have you done updating the ports regarding 20130929 No, I did 'svn co ...' for /usr/ports on an empty machine and compiled all my used ports based on rev r328930. matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: SU+J Lost files after a power failure
David Demelier wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. Any ideas? Should I open a PR? Not sure there is enough to go on for a PR, but something is weird. Friday morning our power went down at home for about three hours after I had already left for work. When I came home I found the router/gateway box was OK. It is still with the old DOS mbr and disklabel scheme, with softupdates, and is a pair of disks gmirrored. The other box is my first foray into the land of GPT, along with SU+J. It was sitting at the 'couldn't mount... Press return for /bin/sh' line. There was an error indicating that replaying one or more journals had failed. I was able to successfully fsck all the other partitions (besides /), then rebooted and system came back up OK. Both of these machines were recently updated to 9.2 Release from 9.1. It has been approximately 9 months, or so, since I last had a power outage like this one. Back then they were still 8.3 I think, did not have SU+J and recovered just fine on their own. This error about the replay of the journal(s) failing is somewhat disconcerting. Beyond that, however, I do not have any other details or data. Nothing to flesh out a PR, but thought I'd mention what I saw in conjunction with your experience. -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: Authorisation Errors on 9.2
On 14/10/2013 06:37, Beeblebrox wrote: Hi, I Inadvertently posted the gnome-keyring bit. That's almost standard error message on FreeBSD-Gnome. The relevant bit for the error is in fact: slim: gkr-pam: no password is available for user However, the user cannot login on a tty without providing a password. For ssh, the same error and dropped connection occurs for all users. sshd was modified to allow root login. All users have valid home directories defined. From /etc/passwd; I wonder if this has anything to do with it? sshd:*:22:22:Secure Shell Daemon:/var/empty:/usr/sbin/*nologin* Could it be a dud /root/.tcshrc? Or /etc/login.conf? The accounts which try to ssh login also login on host proper and do not have any login issues when logging-in directly on host - so I think we can eliminate these problems. I'm now really guessing - I've not tried 9.2-RELEASE. Given these things are usually really obvious when you finally spot them (it happens to me a lot, anyway), here are a few obvious things you could think of in case it helps. First off, ssh is different from a console login so what's in sshd_config matters. That said, the defaults generally work (or used to). In no particular order, in sshd_config: PasswordAuthentication must be yes KerberosOrLocalPasswd probably yes AllowUsers, AllowGroups, DenyUsers and DenyGroups need to be set correctly. ChrootDirectory - this could cause fun if it's set to something. Other things that might be interesting are UseLogin and UsePAM. If this was a fundamental problem with changed defaults in 9.2, I'm sure a lot more people would have complained. Regards, Frank. ___ 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: SU+J Lost files after a power failure
Michael Powell wrote: [snip] The other box is my first foray into the land of GPT, along with SU+J. It was sitting at the 'couldn't mount... Press return for /bin/sh' line. There was an error indicating that replaying one or more journals had failed. I was able to successfully fsck all the other partitions (besides /), then rebooted and system came back up OK. Meant to include also that I booted from a CD with wddiags and ran the Quick test and it found no errors on the disk. [snip] -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
DEFAULT_VERSIONS=
Has the DEFAULT_VERSIONS= been extended to include ports other than python=2.7 python2=2.7 python3=3.3 perl5=5.18 ruby=2.0 tcltk=8.6 as presently shown in UPDATING? Are their plans to extend it to ports like db6, mysql56\*, etcetera? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 05:02:22 -0400 Michael Powell wrote: David Demelier wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. The journalling in SU+J has nothing to do with data integrity. When the system isn't shut-down cleanly, soft-updates are supposed to leave the filesystem in a self-consistent state, except that it may lose track of some freed disk space. The journal allows that space to be recovered without the lengthy background fsck that used to cripple performance. If you are having problems with data integrity you might try gjournal or zfs instead. If you look back at the lists before these were added there was a lot of suspicion about soft-updates and background checks. Some of the problems were explained by some (mostly desktop) drives incorrecty reporting what has been commited to disk - I don't know whether this is still the case. This error about the replay of the journal(s) failing is somewhat disconcerting. I think this is probably a good thing. With background checks you would (if you were looking) occasionally see unexpected soft-update inconsistency during the background check, which would lead to a foreground check on the next boot. ___ 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
vBSDcon: October 25 - 27. 2013 in Herndon, VA
Just a friendly reminder vBSDcon is less than 2 weeks away from October 25 – 27, 2013 in Herndon, VA. Online registrations are open for 9 more days and will close on October 23, 2013. On-site registrations will be available throughout the entirety of vBSDcon. Attendees may register for vBSDcon at http://www.vbsdcon.com/ for USD$75. The US east coast's newest BSD-related conference will feature lightning talks, birds of a feather sessions, and plenary speakers. Speakers include the likes of David Chisnall, Luigi Rizzo, Baptiste Daroussin, Henning Brauer, Reyk Floeter, among others. See the full list of speakers and topics at http://www.vbsdcon.com/. All vBSDcon attendees are invited to join Verisign at a reception dinner at the conference venue on October 25 from 6:00 – 8:00PM Eastern. We look forward to seeing you all there! -- Vincent (Rick) Miller Systems Engineer vmil...@verisign.com t: 703-948-4395 m: 703-581-3068 12061 Bluemont Way, Reston, VA 20190 http://www.vbsdcon.com http://www.verisigninc.com “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.” ___ 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: Reinstall without reformat
On Mon, 14 Oct 2013, Polytropon wrote: On Sun, 13 Oct 2013 23:01:02 -0600 (MDT), Warren Block wrote: On Mon, 14 Oct 2013, Polytropon wrote: On Sun, 13 Oct 2013 13:24:30 -0400, Kenta Suzumoto wrote: Hi all. Is it possible to install FreeBSD without formatting the disk? Yes. The installer supports not formatting existing partitions. The file system characteristica will be kept, possible content will overwritten. Note that superfluous content will also be kept, except of course you previously remove everything. sysinstall supported that, but AFAIK bsdinstall does not. Oh, seems you're right. I've checked The FreeBSD Handbook for the relevant instructions for using bsdinstall at http://www.freebsd.org/doc/handbook/bsdinstall-partitioning.html and http://www.freebsd.org/doc/handbook/bsdinstall-final-warning.html and I didn't find an option to _not_ initialize existing partitions, even though it seems you can assign existing partitions without any problem. The remaining question: Will they be initialized again? It is possible to mount filesystems manually from the shell and have bsdinstall continue with the install without formatting them. It's been a while since I tried that, and I don't recall the exact details. bsdinstall(8) suggests it may be as easy as just having the existing filesystems mounted at /mnt. Still, not something to try without a backup. ___ 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: firefox: after update - version 23: can not swap tabs
On Mon, 14 Oct 2013, O. Hartmann wrote: FF is in my case 24, too: pkg info firefox firefox-24.0,1 Have you done updating the ports regarding 20130929 in /usr/ports/UPDATING? I did on all boxes and on all boxes I did the tab-stickyness is present. Firefox 24 allows tab moves for me on both 9-stable and 10-stable. The pixman update missed some files for me, resolved by using pkg_libchk (from sysutils/bsdadminscripts) to find the ports that needed rebuilding and then rebuilding them. ___ 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: Reinstall without reformat
On Mon, 14 Oct 2013 07:51:15 -0600 (MDT), Warren Block wrote: It is possible to mount filesystems manually from the shell and have bsdinstall continue with the install without formatting them. It's been a while since I tried that, and I don't recall the exact details. bsdinstall(8) suggests it may be as easy as just having the existing filesystems mounted at /mnt. Still, not something to try without a backup. So if I understand everything correctly, the decision logic is -- when partitions do already exist -- as follows: a) existing partitions not mounted: run newfs mount partitions copy files b) existing partitions mounted: do not run newfs copy files The installer itself doesn't seem to give a hint about this logic, even though the manual _might_ suggest it. I haven't examined the source code to fully verify this logic, even though it would be a reasonable approach. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: Reinstall without reformat
The brutal and brute-force approach can work - better if you boot from a USB stick, of course. You can untar base.tzx and kernel.tzx in your /, with filesystems mounted. As Polytropon says, do a backup of what you'll want afterwards. This approach will leave a lot of cruft (old versions of shared libraries, etc.), but will certainly work. Grab the distribution from (in this case, the example is for 9.2, i386) ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.2-RELEASE ___ 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: SU+J Lost files after a power failure
On 14.10.2013 14:39, RW wrote: On Mon, 14 Oct 2013 05:02:22 -0400 Michael Powell wrote: David Demelier wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. The journalling in SU+J has nothing to do with data integrity. When the system isn't shut-down cleanly, soft-updates are supposed to leave the filesystem in a self-consistent state, except that it may lose track of some freed disk space. The journal allows that space to be recovered without the lengthy background fsck that used to cripple performance. If you are having problems with data integrity you might try gjournal or zfs instead. Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? On GNU/Linux, on Windows you will not require anything else to recover your data. I don't want to tweak the filesystem or use something different that the default, as it is the default it's the *warranty* that it is the correct way to protect data for new FreeBSD user's installations IMHO. If you look back at the lists before these were added there was a lot of suspicion about soft-updates and background checks. Some of the problems were explained by some (mostly desktop) drives incorrecty reporting what has been commited to disk - I don't know whether this is still the case. This error about the replay of the journal(s) failing is somewhat disconcerting. I think this is probably a good thing. With background checks you would (if you were looking) occasionally see unexpected soft-update inconsistency during the background check, which would lead to a foreground check on the next boot. ___ 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 ___ 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
Tuning /etc/sysctl.conf
Hi people, I'm very interested to tuning /etc/sysctl.conf according to the specifications of my PC. I've been reading some guides [1], tutorials [2-3], QA [4] and the FreeBSD Handbook's related section 12.12 Tuning with sysctl(8), but I think it's much more convenient if I contrast it with other examples or experienced users. Here is my relevant info outputs for help to improve the sysctl(8) variables. % uname -a FreeBSD freebsd 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Fri Sep 27 03:52:52 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 % dmesg | grep CPU CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2394.06-MHz 686-class CPU) cpu0: ACPI CPU on acpi0 p4tcc0: CPU Frequency Thermal Control on cpu0 % dmesg | grep memory real memory = 2147483648 (2048 MB) avail memory = 2082701312 (1986 MB) % pciconf -lvv | grep -n2 Ethernet 41-sis0@pci0:0:4:0: class=0x02 card=0x80a71043 chip=0x09001039 rev=0x91 hdr=0x00 42-vendor = 'Silicon Integrated Systems [SiS]' 43:device = 'SiS900 PCI Fast Ethernet' 44-class = network 45-subclass = ethernet My /etc/sysctl.conf # $FreeBSD: release/9.2.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 vfs.usermount=1 hw.snd.default_unit=2 kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.shm_allow_removed=1 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.blackhole=1 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.inet.tcp.sendbuf_max=16777216 net.inet.ip.random_id=1 http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel # Allow for up 2 GB of wired memory. vm.max_wired=524288 I will appreciate any input about the subject. --CJPM [1] http://harryd71.blogspot.com.es/2008/10/tuning-freenas-zfs.html [2] https://wiki.freebsd.org/SystemTuning#SYSCTL_TUNING [3] https://wiki.freebsd.org/NetworkPerformanceTuning [4] http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel ___ 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: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 6:34 PM, David Demelier demelier.da...@gmail.com wrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? On GNU/Linux, on Windows you will not require anything else to recover your data. I don't want to tweak the filesystem or use something different that the default, as it is the default it's the *warranty* that it is the correct way to protect data for new FreeBSD user's installations IMHO. Agree :-) SU+J also seems to cause problems on SSD drives: http://lists.freebsd.org/pipermail/freebsd-fs/2013-February/016420.html -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 11:34 AM, David Demelier demelier.da...@gmail.comwrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? As already stated, those measures are to preserve fs integrity eg meta data is in sync. It doesn't ensure that all the outstanding writes are committed to disk in the event of a power outage. On GNU/Linux, on Windows you will not require anything else to recover your data. This is complete garbage when using default settings as you imply below. The default for ext3 on basically every distro still using ext3 is an ordered journal and don't even get started on ext4. NTFS by default can/will also lose data on a power outage. I don't want to tweak the filesystem or use something different that the default, as it is the default it's the *warranty* that it is the correct way to protect data for new FreeBSD user's installations IMHO. There is no *warranty* as explicitly stated in http://www.freebsd.org/copyright/freebsd-license.html The behavior you wish would slow down disk writes by an order of magnitude and is already available to users willing to use non-default settings. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 6:47 PM, Adam Vande More amvandem...@gmail.com wrote: On Mon, Oct 14, 2013 at 11:34 AM, David Demelier demelier.da...@gmail.comwrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? As already stated, those measures are to preserve fs integrity eg meta data is in sync. It doesn't ensure that all the outstanding writes are committed to disk in the event of a power outage. Then why random files gets damaged as well even they are not accessed/written on power loss? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: Tuning /etc/sysctl.conf
Mmm... just a correction in /etc/sysctl.conf, it seems that by mistake I've copied a website link into the file. Sorry, it was a copy-paste error :) % cat /etc/sysctl.conf # $FreeBSD: release/9.2.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 vfs.usermount=1 hw.snd.default_unit=2 kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.shm_allow_removed=1 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.blackhole=1 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.inet.tcp.sendbuf_max=16777216 net.inet.ip.random_id=1 # Allow for up 2 GB of wired memory. vm.max_wired=524288 2013/10/14 Carlos Jacobo Puga Medina cjpug...@gmail.com Hi people, I'm very interested to tuning /etc/sysctl.conf according to the specifications of my PC. I've been reading some guides [1], tutorials [2-3], QA [4] and the FreeBSD Handbook's related section 12.12 Tuning with sysctl(8), but I think it's much more convenient if I contrast it with other examples or experienced users. Here is my relevant info outputs for help to improve the sysctl(8) variables. % uname -a FreeBSD freebsd 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Fri Sep 27 03:52:52 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 % dmesg | grep CPU CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2394.06-MHz 686-class CPU) cpu0: ACPI CPU on acpi0 p4tcc0: CPU Frequency Thermal Control on cpu0 % dmesg | grep memory real memory = 2147483648 (2048 MB) avail memory = 2082701312 (1986 MB) % pciconf -lvv | grep -n2 Ethernet 41-sis0@pci0:0:4:0: class=0x02 card=0x80a71043 chip=0x09001039 rev=0x91 hdr=0x00 42-vendor = 'Silicon Integrated Systems [SiS]' 43:device = 'SiS900 PCI Fast Ethernet' 44-class = network 45-subclass = ethernet My /etc/sysctl.conf # $FreeBSD: release/9.2.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 vfs.usermount=1 hw.snd.default_unit=2 kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.shm_allow_removed=1 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.blackhole=1 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.inet.tcp.sendbuf_max=16777216 net.inet.ip.random_id=1 http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel # Allow for up 2 GB of wired memory. vm.max_wired=524288 I will appreciate any input about the subject. --CJPM [1] http://harryd71.blogspot.com.es/2008/10/tuning-freenas-zfs.html [2] https://wiki.freebsd.org/SystemTuning#SYSCTL_TUNING [3] https://wiki.freebsd.org/NetworkPerformanceTuning [4] http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel ___ 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: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 11:50 AM, CeDeROM cede...@tlen.pl wrote: Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Prove they weren't. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 6:56 PM, Adam Vande More amvandem...@gmail.com wrote: On Mon, Oct 14, 2013 at 11:50 AM, CeDeROM cede...@tlen.pl wrote: Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Prove they weren't. Hmm, maybe /etc/pwd.db as David mentioned? This is updated on password change, which does not happen all the time.. so why it was damaged when no write occured..? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: Tuning /etc/sysctl.conf
On Mon, 14 Oct 2013 18:35:49 +0200 Carlos Jacobo Puga Medina cjpug...@gmail.com wrote: Hi people, I'm very interested to tuning /etc/sysctl.conf according to the specifications of my PC. As a general rule it is more appropriate to think of tuning in terms of the workload you intend to apply to your PC. Most changes you can make will benefit some workflows at the cost of making others less efficient. -- Steve O'Hara-Smith st...@sohara.org ___ 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: SU+J Lost files after a power failure
On 10/14/2013 12:50 PM, CeDeROM wrote: On Mon, Oct 14, 2013 at 6:47 PM, Adam Vande More amvandem...@gmail.com wrote: On Mon, Oct 14, 2013 at 11:34 AM, David Demelier demelier.da...@gmail.comwrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? As already stated, those measures are to preserve fs integrity eg meta data is in sync. It doesn't ensure that all the outstanding writes are committed to disk in the event of a power outage. Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Random files can be affected because the sectors of the hard disk containing the directory entries for those files, not the file data itself, may be damaged (ie: the directory was in the process of being written OR the pointer to that SECTOR was in the process of being written). It doesn't mean a file was in active use, just that a chunk of the disk with data relevant to that file was. Keep in mind, one sector of disk may have data for a dozen files in it (or more). Damage doesn't have to occur because a given file was in use at the time of a crash. If your power grid is prone to failures or blips, I strongly suggest investing in a UPS. Brad ___ 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: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 7:09 PM, Brad Mettee bmet...@pchotshots.com wrote: On 10/14/2013 12:50 PM, CeDeROM wrote: Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Random files can be affected because the sectors of the hard disk containing the directory entries for those files, not the file data itself, may be damaged (ie: the directory was in the process of being written OR the pointer to that SECTOR was in the process of being written). It doesn't mean a file was in active use, just that a chunk of the disk with data relevant to that file was. Keep in mind, one sector of disk may have data for a dozen files in it (or more). Damage doesn't have to occur because a given file was in use at the time of a crash. Isn't there Journal to prevent and reverse such damage? If your power grid is prone to failures or blips, I strongly suggest investing in a UPS. I have UPS in my desktop and also I am working on a laptop, so the power supply is not the only possible cause of system crash.. this may be faulty driver, hardware failure, kernel panic, etc. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: Tuning /etc/sysctl.conf
Hi Steve, I use it as a paticular desktop PC. Well, if you need more details about it, please, let me know. What do you think about current tuning? Thanks --CJPM 2013/10/14 Carlos Jacobo Puga Medina cjpug...@gmail.com Mmm... just a correction in /etc/sysctl.conf, it seems that by mistake I've copied a website link into the file. Sorry, it was a copy-paste error :) % cat /etc/sysctl.conf # $FreeBSD: release/9.2.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 vfs.usermount=1 hw.snd.default_unit=2 kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.shm_allow_removed=1 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.blackhole=1 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.inet.tcp.sendbuf_max=16777216 net.inet.ip.random_id=1 # Allow for up 2 GB of wired memory. vm.max_wired=524288 2013/10/14 Carlos Jacobo Puga Medina cjpug...@gmail.com Hi people, I'm very interested to tuning /etc/sysctl.conf according to the specifications of my PC. I've been reading some guides [1], tutorials [2-3], QA [4] and the FreeBSD Handbook's related section 12.12 Tuning with sysctl(8), but I think it's much more convenient if I contrast it with other examples or experienced users. Here is my relevant info outputs for help to improve the sysctl(8) variables. % uname -a FreeBSD freebsd 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Fri Sep 27 03:52:52 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 % dmesg | grep CPU CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2394.06-MHz 686-class CPU) cpu0: ACPI CPU on acpi0 p4tcc0: CPU Frequency Thermal Control on cpu0 % dmesg | grep memory real memory = 2147483648 (2048 MB) avail memory = 2082701312 (1986 MB) % pciconf -lvv | grep -n2 Ethernet 41-sis0@pci0:0:4:0: class=0x02 card=0x80a71043 chip=0x09001039 rev=0x91 hdr=0x00 42-vendor = 'Silicon Integrated Systems [SiS]' 43:device = 'SiS900 PCI Fast Ethernet' 44-class = network 45-subclass = ethernet My /etc/sysctl.conf # $FreeBSD: release/9.2.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 vfs.usermount=1 hw.snd.default_unit=2 kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.shm_allow_removed=1 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.blackhole=2 net.inet.tcp.delayed_ack=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.blackhole=1 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.inet.tcp.sendbuf_max=16777216 net.inet.ip.random_id=1 http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel # Allow for up 2 GB of wired memory. vm.max_wired=524288 I will appreciate any input about the subject. --CJPM [1] http://harryd71.blogspot.com.es/2008/10/tuning-freenas-zfs.html [2] https://wiki.freebsd.org/SystemTuning#SYSCTL_TUNING [3] https://wiki.freebsd.org/NetworkPerformanceTuning [4] http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel ___ 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: FreeBSD, Centos and ZFS
On Oct 12, 2013, at 10:56 AM, Mark Felder wrote: On Sat, Oct 12, 2013, at 10:53, aurfalien wrote: Hi, I would like to first say that by no means is this a hey, why is my Mac faster then my PC kind of email. I'm really hoping its an LSI driver issue. It may very well be an LSI firmware issue. What are the firmwares for those HBAs? Hi, So the firmware versions are as follows; Intel RS25GB008 which is a rebadged LSI 9207-8e which uses the LSI 2308 controller; Intel firmware13.00.66.00-IT LSI 9206-16e which uses the LSI 2308 controller as well; LSI firmware 17.00.01.00-IT Should I specifically set any of the card settings like hook int or bypass int hook... etc...? - aurf ___ 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: SU+J Lost files after a power failure
On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. For ext3, https://www.kernel.org/doc/Documentation/filesystems/ext3.txt explains the different modes, with 'ordered' being default: Data Mode - There are 3 different data modes: * writeback mode In data=writeback mode, ext3 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext3 performance. * ordered mode In data=ordered mode, ext3 only officially journals metadata, but it logically groups metadata and data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode. * journal mode data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all other modes. -- Bruce Cran ___ 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: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 18:34:36 +0200 David Demelier wrote: On 14.10.2013 14:39, RW wrote: If you are having problems with data integrity you might try gjournal or zfs instead. Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? SU+J isn't a journalled filesytem, it's a filesystem with soft-updates that journals information about free space so it can be recovered without having to go through the whole filesystem. ___ 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: Advice sought on Portmaster -Faf and deleted ports
Hi, I'm following the recipe at the end of man portmaster for deleting and reinstalling all my ports, which I have done many times in the past. This time, I am getting errors on the portmaster -Faf step involving deleted ports, and I'm not sure how to deal with this easily. What errors, exactly? Well, for example: portmaster -Faf it starts to fetch a bunch of files it finds a port which has been deleted, such as linux-base-fc4 and it says, linux-base-fc4 has been deleted. terminating terminating terminating etc. So, I am seeking expert advice here. Is there a way to automate this and keep myself out of trouble, or do I need to do a 'port-by-port' upgrade of each port? It should just work. Have you converted to pkgng? I dream of the day that the ports system will just work. I don't use binary packages, are you saying that pkgng will deal with this issue automatically? Thanks, Scott ___ 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: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran br...@cran.org.uk wrote: On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Or to do a filesystem check after crash..? Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? That would be helpful for development systems I guess :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: SU+J Lost files after a power failure
On 10/14/2013 7:33 PM, CeDeROM wrote: Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Or to do a filesystem check after crash..? Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? That would be helpful for development systems I guess :-) As I understand it UFS+J gives the same reliability as UFS with a normal fsck after a crash, so on a development system the only ways to improve the situation would be to mount with the 'sync' option, disable write caching on the disk or to switch to a different filesystem like ZFS. -- Bruce Cran ___ 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: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 1:33 PM, CeDeROM cede...@tlen.pl wrote: Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Please explain the logic in which this helps anything. Or to do a filesystem check after crash..? Already standard behavior as implicitly seen in this thread. Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? No and any fs that requires such a system is broken by design. That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? mount -o sync or use ZFS. Both require hardware that correctly report success to fsync. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 1:43 PM, Adam Vande More amvandem...@gmail.comwrote: mount -o sync should be mount sync -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Oct 14, 2013, at 11:33 AM, CeDeROM cede...@tlen.pl wrote: On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran br...@cran.org.uk wrote: On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? You shouldn't ever need to recheck the filesystem if it was shutdown cleanly. However, it doesn't hurt to fire off an fsck once a year or so just to look for any unexpected issues. Or to do a filesystem check after crash..? Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? That would assume disabling journal and soft updates journaling I guess..? /etc/rc.conf should support something like the following to do what you ask: fsck_y_enable=YES background_fsck=NO force_fsck=YES What would be the best option for best data integrity in case of crash? That would be helpful for development systems I guess :-) Well, you can use mount -o sync and disable write caching via hw.ata.wc=0 or similar depending on what kind of drives you use. This will cause a massive loss of write performance, but will greatly improve reliability-- i.e. fsync() and such are not as likely to lie about whether bits have made it to disk, even in the face of hardware which lies about ATA_FLUSHCACHE (or SCSI SYNCHRONIZE CACHE, etc). Regards, -- -Chuck ___ 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: SU+J Lost files after a power failure
Thank you all for good hints! This will come handy! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
NFS locks rpcbind port = 0 failed? - try #2
This is a continuation of 9.1 VM nfs3 locks over VPN - trying a different angle maybe it'll jostle someones memory. I now have a FreeBSD 9.2 VM at an offsite hosting company. hostname nl101vpn OpenVPN is installed on it, routed not bridged mode. I have multiple OSs installed on local network. I'm already exportings NFS off 9.1 with working locks. export nfsv3 or nfsv4 from nl101vpn - locks do not work. export nfsv3 from any local system, mount on nl101vpn - locks work. export nfsv3 from locally installed VM, mount on any local host or nl101vpn - locks work. No OpenVPN installed on it though. I even ran a tcpdump to see if something was getting lost - both sides match, nothing is getting dropped nl101vpn - /var/log/messages: Oct 14 12:21:01 nl101 kernel: NLM: failed to contact remote rpcbind, stat = 0, port = 0 (why port 0?) Oct 14 12:23:02 nl101 last message repeated 109 times Oct 14 12:25:48 nl101 last message repeated 177 times So I haven't exhausted every combination, or completely 100% replicated whats happening offsite, but it's getting pretty ridiculous now... I'm lost, and I need locking. Help :) ___ 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: SU+J Lost files after a power failure
On Mon, 14 Oct 2013, Bruce Cran wrote: On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. This discussion skirts the critical issue - are files that are not open for writing endangered? No description of the uses of journaling can be considered informative if it doesn't address that explicitly. As a naive user I have always assumed that once closed, a file was invulnerable to improper shutdowns, but this discussion shakes that belief. I expect the answer may be different for SSD and spinning disks. dan feenberg ___ 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: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 11:48:18 -0700 Charles Swiger wrote: Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. Journalling removes the need for the background fsck which only recovers lost space. With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, My understanding is that the journal does nothing to restore the filesystem other than keep track of orphaned memory. In all other respect it's the job of soft-updates to keep the filesystem in an OK state. When it doesn't you need a foreground check. but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. I think if the journal fails, you would really need to run at least a foreground preen, maybe a full fsck. ___ 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: SU+J Lost files after a power failure
Charles Swiger wrote: [snip] Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. In my case the journal replay failed, with an error to that effect. All partitions other than / failed to mount and after hitting enter at the .../bin/sh prompt performed manual fsck on all of them, which found and fixed some stuff. Then shutdown -r and everything came up fine (clean) afterwards. Net result was no data loss for me. [snip] -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: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 11:48:18 -0700 Charles Swiger wrote: fsck_y_enable=YES One of the most annoying things about SU+J is that fsck asks if you want to use the journal. So fsck -y wont do a proper check unless the journal replay fails. ___ 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: Advice sought on Portmaster -Faf and deleted ports
On Mon, 14 Oct 2013, Scott Ballantyne wrote: I'm following the recipe at the end of man portmaster for deleting and reinstalling all my ports, which I have done many times in the past. This time, I am getting errors on the portmaster -Faf step involving deleted ports, and I'm not sure how to deal with this easily. What errors, exactly? Well, for example: portmaster -Faf it starts to fetch a bunch of files it finds a port which has been deleted, such as linux-base-fc4 and it says, linux-base-fc4 has been deleted. terminating terminating terminating etc. That's correct. linux_base-fc4 is long gone (years), replaced by linux_base-f10. portmaster sees no way to upgrade that port, so evidently it quits. If you have ports that far out of date, the upgrade process is going to be long. Ports where the system does not know the replacement will have to be handled manually. So, I am seeking expert advice here. Is there a way to automate this and keep myself out of trouble, or do I need to do a 'port-by-port' upgrade of each port? It should just work. Have you converted to pkgng? I dream of the day that the ports system will just work. I don't use binary packages, are you saying that pkgng will deal with this issue automatically? No, the concern was that you might have already converted to pkgng but still used the old package tools. ___ 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: SU+J Lost files after a power failure
On 14.10.2013 20:08, RW wrote: On Mon, 14 Oct 2013 18:34:36 +0200 David Demelier wrote: On 14.10.2013 14:39, RW wrote: If you are having problems with data integrity you might try gjournal or zfs instead. Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? SU+J isn't a journalled filesytem, it's a filesystem with soft-updates that journals information about free space so it can be recovered without having to go through the whole filesystem. Okay, but why the fsck didn't run by itself to detect that the journal didn't replayed correctly (if I understanding well) to correct the issues? ___ 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: SU+J Lost files after a power failure
On 14.10.2013 18:47, Adam Vande More wrote: There is no *warranty* as explicitly stated in http://www.freebsd.org/copyright/freebsd-license.html Aha, please don't play on words ;-). I think you understood I was speaking about the filesystem state not a lawyer issue. ___ 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: SU+J Lost files after a power failure
On 14.10.2013 20:43, Adam Vande More wrote: On Mon, Oct 14, 2013 at 1:33 PM, CeDeROM cede...@tlen.pl mailto:cede...@tlen.pl wrote: Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Please explain the logic in which this helps anything. Or to do a filesystem check after crash..? Already standard behavior as implicitly seen in this thread. Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? No and any fs that requires such a system is broken by design. That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? mount -o sync or use ZFS. Both require hardware that correctly report success to fsync. I personnally love ZFS and use it massively on my server, but for a desktop I think this is a real overkill. Also I don't have so much RAM to waste for that. I think UFS is enough, however as a modern operating system I don't expect any data corruption by default using SU+J. The filesystem domain is not a thing I really know deeply, so thanks for all you explanation. PS: the power failure is not the only way that does not shutdown cleanly the system. There are kernel panics, crash and such of course. Those which appears sometimes too. Regards, ___ 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: SU+J Lost files after a power failure
Hi-- On Oct 14, 2013, at 11:51 AM, Daniel Feenberg feenb...@nber.org wrote: This discussion skirts the critical issue - are files that are not open for writing endangered? No description of the uses of journaling can be considered informative if it doesn't address that explicitly. As a naive user I have always assumed that once closed, a file was invulnerable to improper shutdowns, but this discussion shakes that belief. Well, it's good to be a little paranoid if the data matters. :-) First, unless you call fsync() before close() and your OS and/or drive hardware isn't being deceptive when fsync() returns about whether the bits have made it to permanent storage, then you might be surprised at just how long the unwritten buffers containing the last updates to the file data take to get properly flushed to disk. I expect the answer may be different for SSD and spinning disks. Second, this is an excellent point: however, it also applies to anything where the actual hardware block size does not match the device blocksize that the filesystem thinks it has-- so new 4K sector rotational disks also have some risk. The basic issue with SSDs is that you (or the drive firmware, more precisely) need to read in an entire hardware sector, update the portion with changes in cache memory, do a bulk-erase of that block, and then scribble that back out. Good drive firmware actually writes out to a different block than the original for wear-leveling purposes and only updates the flash translation layer once the new version of that block is written. That makes the drive mostly immune to major data integrity issues even if powered off in the middle of the process. Less-than-good firmware, aka buggy firmware, can lead from power-failure to data loss of files which were not being modified at the time. And may you possess recent working backups if the FTL somehow ever gets confused! Regards, -- -Chuck ___ 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: SU+J Lost files after a power failure
On Oct 14, 2013, at 12:41 PM, RW rwmailli...@googlemail.com wrote: On Mon, 14 Oct 2013 11:48:18 -0700 Charles Swiger wrote: Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. Journalling removes the need for the background fsck which only recovers lost space. That and inode link changes (ie, adding or removing files from a directory). With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, My understanding is that the journal does nothing to restore the filesystem other than keep track of orphaned memory. In all other respect it's the job of soft-updates to keep the filesystem in an OK state. Yes, SU is supposed to reorder filesystem operations to provide some level of ACID transaction semantics-- and the journal helps that by avoiding the need for bgfsck. When it doesn't you need a foreground check. but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. I think if the journal fails, you would really need to run at least a foreground preen, maybe a full fsck. Yes. Regards, -- -Chuck ___ 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: Do I really have to install 80 packages?
On 10/13/13 17:38, Thomas Mueller wrote: On the question of playing Adobe Flash in FreeBSD, could one use the MS-Windows 32-bit version with (i386-)Wine? I plan to try that. Apparently that won't solve much. The primary issue now with watching flash movies is the drm - on linux it somehow uses hal and dbus, on windows it uses the registry. ___ 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: Advice sought on Portmaster -Faf and deleted ports
On Mon, 14 oct 2013, Warren Block wbl...@wonkity.com wrote: On Mon, 14 Oct 2013, Scott Ballantyne wrote: What errors, exactly? Well, for example: portmaster -Faf it starts to fetch a bunch of files it finds a port which has been deleted, such as linux-base-fc4 and it says, linux-base-fc4 has been deleted. terminating terminating terminating etc. That's correct. linux_base-fc4 is long gone (years), replaced by linux_base-f10. portmaster sees no way to upgrade that port, so evidently it quits. I understand why portmaster quits that port. It does seem like a bit of over-kill to quit updating ALL ports because one is long gone. Seems like it could do the others. If you have ports that far out of date, the upgrade process is going to be long. Ports where the system does not know the replacement will have to be handled manually. Actually, the last time I updated my ports was when I installed 9.0, and I used the portmaster 'nuke all ports' method I was trying to day. Since then, several dozen ports of been 'deleted' or 'renamed', not just the linux_base-fc4. Seems in the case of ports which have been renamed or replaced, this could in fact be simply automated in most cases. Best, Scott -- s...@ssr.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Advice sought on Portmaster -Faf and deleted ports
On Mon, Oct 14, 2013 at 6:35 PM, Scott Ballantyne s...@ssr.com wrote: I understand why portmaster quits that port. Because it has no choice. It does seem like a bit of over-kill to quit updating ALL ports because one is long gone. Seems like it could do the others. So it should continue on and potentially build 1000's of ports with broken linking and dependencies? Portupgrade will do this if you tell it. Try it out and see what fun you can create. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD, Centos and ZFS
On Oct 12, 2013, at 10:56 AM, Mark Felder wrote: On Sat, Oct 12, 2013, at 10:53, aurfalien wrote: Hi, I would like to first say that by no means is this a hey, why is my Mac faster then my PC kind of email. I'm really hoping its an LSI driver issue. It may very well be an LSI firmware issue. What are the firmwares for those HBAs? Upon doing this; sysctl -a | grep mps I get this; dev.mps.0.driver_version: 14.00.00.01-fbsd LSIs site mentions the latest drives at being 17.00.00.00 I'll go ahead and install the latest to see what happens. Whats the best way to do this, I assume build it and load via loader.conf? - aurf ___ 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: Advice sought on Portmaster -Faf and deleted ports
On Mon, 14 Oct 2013, Scott Ballantyne wrote: On Mon, 14 oct 2013, Warren Block wbl...@wonkity.com wrote: On Mon, 14 Oct 2013, Scott Ballantyne wrote: What errors, exactly? Well, for example: portmaster -Faf it starts to fetch a bunch of files it finds a port which has been deleted, such as linux-base-fc4 and it says, linux-base-fc4 has been deleted. terminating terminating terminating etc. That's correct. linux_base-fc4 is long gone (years), replaced by linux_base-f10. portmaster sees no way to upgrade that port, so evidently it quits. I understand why portmaster quits that port. It does seem like a bit of over-kill to quit updating ALL ports because one is long gone. Seems like it could do the others. Some of them. It could not update any ports that depend on missing ports, which conflicts with the -a meaning all. If you have ports that far out of date, the upgrade process is going to be long. Ports where the system does not know the replacement will have to be handled manually. Actually, the last time I updated my ports was when I installed 9.0, and I used the portmaster 'nuke all ports' method I was trying to day. Since then, several dozen ports of been 'deleted' or 'renamed', not just the linux_base-fc4. Seems in the case of ports which have been renamed or replaced, this could in fact be simply automated in most cases. I think it does handle renamed ports. Whether the ones it does not handle are due to missing functionality or because they are difficult or impossible to handle, don't know. ___ 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: Advice sought on Portmaster -Faf and deleted ports
Adam Vande More wrote: It does seem like a bit of over-kill to quit updating ALL ports because one is long gone. Seems like it could do the others. So it should continue on and potentially build 1000's of ports with broken linking and dependencies? Portupgrade will do this if you tell it. Try it out and see what fun you can create. Not a single program on my system depended on that program being rebuilt. Portmaster should certainly refuse to rebuild anything that did, of course. ___ 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: Advice sought on Portmaster -Faf and deleted ports
On Mon 14 Oct 2013 Warren Block wrote: On Mon, 14 Oct 2013, Scott Ballantyne wrote: On Mon, 14 oct 2013, Warren Block wbl...@wonkity.com wrote: On Mon, 14 Oct 2013, Scott Ballantyne wrote: Actually, the last time I updated my ports was when I installed 9.0, and I used the portmaster 'nuke all ports' method I was trying to day. Since then, several dozen ports of been 'deleted' or 'renamed', not just the linux_base-fc4. Seems in the case of ports which have been renamed or replaced, this could in fact be simply automated in most cases. I think it does handle renamed ports. Whether the ones it does not handle are due to missing functionality or because they are difficult or impossible to handle, don't know. Such was not my experience, Warren. And actually, a google search while I was trying to solve this turned up many reports of the same problem over the past years. ___ 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: Advice sought on Portmaster -Faf and deleted ports
On Mon, Oct 14, 2013 at 9:48 PM, Scott Ballantyne s...@ssr.com wrote: Adam Vande More wrote: It does seem like a bit of over-kill to quit updating ALL ports because one is long gone. Seems like it could do the others. So it should continue on and potentially build 1000's of ports with broken linking and dependencies? Portupgrade will do this if you tell it. Try it out and see what fun you can create. Not a single program on my system depended on that program being rebuilt. And what about libs it may have left behind and other ports picking up faulty info? Then you build unsupported and faultly packages and complain to the list when something doesn't work. Just follow /usr/ports/UPDATING as advised instead of your shortcuts. Portmaster should certainly refuse to rebuild anything that did, of course. Exactly what it did. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
