Re: Removing fdisk and bsdlabel (legacy partition tools)
Sounds like a custom mfsBSD or Frenzy CD/USB would be better suited to these bare-metal rescue setups. Something that has the specific tools you need already installed. I know I've kept various versions of these CD images around for just this purpose. I always found them nicer to use than the FreeBSD install CDs in rescue mode, as there's a fully-functional FreeBSD install to work from, including the ability to install packages temporarily. -- Freddie Cash fjwc...@gmail.com
Re: RFC: NFS over TLS stats
On Tue, Oct 24, 2023 at 10:56 PM Rick Macklem wrote: > Garrett Wollman asked me via email how a server > admin could tell what usage NFS over TLS was > happening. > > I admitted that there was nothing. I have come up > with a patch that generates the following: > kern.rpctls.snd_tls_msgbytes: 21508 > kern.rpctls.snd_msgbytes: 20828 > kern.rpctls.snd_tls_msgcnt: 57 > kern.rpctls.snd_msgcnt: 58 > kern.rpctls.rcv_tls_msgbytes: 12336 > kern.rpctls.rcv_msgbytes: 12072 > kern.rpctls.rcv_tls_msgcnt: 57 > kern.rpctls.rcv_msgcnt: 58 > Have no technical comments, but a style suggestion: put the tls at the end to make the output look nicer. :) kern.rpctls.snd_msgbytes: 21508 > kern.rpctls.snd_msgbytes_tls: 20828 > kern.rpctls.snd_msgcnt: 58 > kern.rpctls.snd_msgcnt_tls: 57 > kern.rpctls.rcv_msgbytes: 12072 > kern.rpctls.rcv_tmsgbytes_tls: 12336 > kern.rpctls.rcv_msgcnt: 58 kern.rpctls.rcv_msgcnt_tls: 57 -- Freddie Cash fjwc...@gmail.com
Re: Which ath(4) cards are currently supported?
On Mon, Apr 4, 2022 at 11:01 AM Chris wrote: > OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new > laptop I picked up. But 80211ac isn't yet supported. :-( > OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE > Hardware notes[1] which indicates: > The ath(4) driver supports all Atheros Cardbus and PCI cards, except > those that are based on the AR5005VL chipset. > Note: PCI means PCI, not PCIe. :) The ath(4) driver supports the old PCI and CardBus adapters. It doesn't support PCIe, USB, M.2, or other formfactor adapters. While slightly ambiguous, the hardware notes are technically correct. -- Freddie Cash fjwc...@gmail.com
Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool"
[message chopped and butchered, don't follow the quotes, it's just to show some bits together from different messages] On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > > > For reference, as things now are: > > > > > > # gpart show > > > => 40 937703008 nda0 GPT (447G) > > > 40 532480 1 efi (260M) > > > 532520 2008- free - (1.0M) > > > 534528 937166848 2 freebsd-zfs (447G) > > > 937701376 1672- free - (836K) > > > . . . > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > labelclear -f /dev/nda0p2" > > > > >> > >> I did not extract and show everything that I'd tried but > >> there were examples of: > >> > >> # zpool labelclear -f /dev/nda0p2 > >> failed to clear label for /dev/nda0p2 > > The start of the problem looked like (console context, > so messages interlaced): > > # zpool create -O compress=lz4 -O atime=off -f -tzopt0 zpopt0 /dev/nvd0 > GEOM: nda0: the primary GPT table is corrupt or invalid. > GEOM: nda0: using the secondary instead -- recovery strongly advised. > cannot create 'zpopt0': no such pool or dataset > # Sep 16 12:19:31 CA72_4c8G_ZFS ZFS[]: vdev problem, zpool=zopt0 > path=/dev/nvd0 type=ereport.fs.zfs.vdev.open_failed > > The GPT table was okay just prior to the command. > So I recovered it. > It looks like you're trying to use a disk partition for a ZFS pool (nda0p2), but then you turn around and use the entire drive (nvd0) for the pool which clobbers the GPT. You need to be consistent in using partitions for all commands. You're also mixing up your disk device nodes for the different commands; while they are just different names for the same thing, it's best to be consistent. GEOM is built out of layers (or more precisely, "containers" as it specifies a new start and end point on the disk), which is very powerful. But it's also very easy to make a mess of things when you start accessing things outside of the layers. :) And ZFS labelclear option is the nuclear option that tends to remove everything ZFS-related, and everything GPT-related; although I've never seen it used on a partition before, usually just the disk. Best bet in this situation is to just zero out the entire disk (dd if=/dev/zero of=/dev/nda0 bs=1M), and start over from scratch. Create a new GPT. Create new partitions. Use the specific partition with the "zpool create" command. -- Freddie Cash fjwc...@gmail.com
Re: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K
Sorry, meant 256 KB or 512 KB, not MB! On Thu, Feb 11, 2021 at 4:43 PM Freddie Cash wrote: > On Thu, Feb 11, 2021 at 4:35 PM Russell L. Carter > wrote: > >> Greetings, >> >> I really want to jump from stable/12 to stable/13 but one thing is >> causing a hesitancy. And that is, my main raidz2 system has >> a system boot zfs mirror pair that has boot partition size >> (Mediasize) of 64K, and when I tried to zpool upgrade that pool a >> year or 2 ago I got some scary message something like "boot >> partition size is not large enough". I asked about this on the >> lists but never received an answer. So, laziness required me >> to ignore the problem and not zpool upgrade any of my 15 or so >> zpools in the interim. >> >> A few weeks ago I tried to make buildworld/installworld upgrade >> 12->13 but the boot failed in the mounting filesystems phase with it >> couldn't find a bootable target. So after restoring 12 I decided >> to wait a bit. In the interim I have upgraded every zpool but that >> one system pool. All the other freebsd-boot partitions have a size >> of 512K. >> >> So what is the current advice? Is a freebsd-boot partition size >> of 64K laughably obsolete, and I should get with the program and >> repartition those disks, or can I march blindly into the upgrade? >> >> I guess I just want to understand where these sizes are going in >> the future. >> >> That is laughably small and you need to enter the 21st century. ;) > > I believe the recommendation is 256 MB or even 512 MB these days. > > If you partitioned your disks using "-a 1M" with gpart(8) for the > freebsd-zfs partition, then you'll have some slack space between it and the > freebsd-boot partition. Just delete the freebsd-boot partition and create a > larger one in it's place. I did something similar with some drives that > were part of a separate storage pool that I wanted to make bootable, by > creating a freebsd-boot partition in the slack space before the freebsd-zfs > partition. > > If you don't have that slack space at the front, you will need to detach > one of the drives from the mirror, re-partition it, then attach it back to > the mirror. Rinse and repeat for the other side. ZFS shouldn't notice the > pool is smaller by 1 MB (there's some internal slack space to allow you to > add drives that are labelled as the same size, but actually have different > numbers of sectors). > > Cheers, > Freddie > -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K
On Thu, Feb 11, 2021 at 4:35 PM Russell L. Carter wrote: > Greetings, > > I really want to jump from stable/12 to stable/13 but one thing is > causing a hesitancy. And that is, my main raidz2 system has > a system boot zfs mirror pair that has boot partition size > (Mediasize) of 64K, and when I tried to zpool upgrade that pool a > year or 2 ago I got some scary message something like "boot > partition size is not large enough". I asked about this on the > lists but never received an answer. So, laziness required me > to ignore the problem and not zpool upgrade any of my 15 or so > zpools in the interim. > > A few weeks ago I tried to make buildworld/installworld upgrade > 12->13 but the boot failed in the mounting filesystems phase with it > couldn't find a bootable target. So after restoring 12 I decided > to wait a bit. In the interim I have upgraded every zpool but that > one system pool. All the other freebsd-boot partitions have a size > of 512K. > > So what is the current advice? Is a freebsd-boot partition size > of 64K laughably obsolete, and I should get with the program and > repartition those disks, or can I march blindly into the upgrade? > > I guess I just want to understand where these sizes are going in > the future. > > That is laughably small and you need to enter the 21st century. ;) I believe the recommendation is 256 MB or even 512 MB these days. If you partitioned your disks using "-a 1M" with gpart(8) for the freebsd-zfs partition, then you'll have some slack space between it and the freebsd-boot partition. Just delete the freebsd-boot partition and create a larger one in it's place. I did something similar with some drives that were part of a separate storage pool that I wanted to make bootable, by creating a freebsd-boot partition in the slack space before the freebsd-zfs partition. If you don't have that slack space at the front, you will need to detach one of the drives from the mirror, re-partition it, then attach it back to the mirror. Rinse and repeat for the other side. ZFS shouldn't notice the pool is smaller by 1 MB (there's some internal slack space to allow you to add drives that are labelled as the same size, but actually have different numbers of sectors). Cheers, Freddie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When is 'zpool offline' required?
On Mon, Feb 8, 2021 at 10:10 AM joe mcguckin wrote: > I was just playing around with a test ZFS system and was running through > replacing a bad drive and I forgot to issue a ‘zpool offline’ command. > Everything seemed to go ok anyway. The system started resilvering, etc. > When is ‘zpool required’? Under what conditions can I omit it? > If the drive is dying but still working, then using "zpool offline" is recommended, to tell the pool to stop using the drive. This is also handy if there's going to be a delay between "noticed the drive is dying" and "have a replacement drive available". If the drive is completely dead, then most likely it will be dropped from the pool automatically by ZFS, so "zpool offline" isn't needed. While it's generally "better" to offline drives, ZFS is designed to withstand drives dropping off without warning. > Is there a dedicated mailing list for ZFS user questions? > There's a zfs-discuss mailing list run by the OpenZFS project. There isn't a FreeBSD ZFS-specific mailing list, but there is a freebsd-fs@ mailing list for everything filesystem related (UFS, ZFS, mfs, NFS, etc). Cheers, Freddie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri., Jan. 15, 2021, 9:41 a.m. Juraj Lutter, wrote: > > On 15 Jan 2021, at 18:26, Freddie Cash wrote: > > > > /var/run/dmesg.boot includes all output from dmesg for the current boot. > No > > need to manually redirect dmesg output to a file or play with buffer > sizes. > > :) Just upload that file. > > On boot, dmesg is saved to dmesg.boot quite lately and start of the > circular > buffer can already be rewritten. > Really? Interesting. Haven't run into that (not saying it can't happen). I always thought it was essentially streamed to that file once / or /var was mounted. Now I'll have to read some RC scripts to see. :) Thanks for the info. Cheers, Freddie Typos due to smartphone keyboard. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri., Jan. 15, 2021, 8:47 a.m. Mikaël Urankar, wrote: > On 15/01/2021 17:35, Konstantin Belousov wrote: > > It is clipped at the start, and that was the information which I need. > > Add something like > > kern.msgbufsize=1048576 > > to /boot/loader.conf and try again. I need to see the lines starting > with > > > > CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU) > >Origin="GenuineIntel" Id=0x806ea Family=0x6 Model=0x8e Stepping=10 > > > Features=0xbfebfbff > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > ... > > > > (well, this is my w/s, your CPU would be different of course). > > > Thanks, I've updated the file on freefall. /var/run/dmesg.boot includes all output from dmesg for the current boot. No need to manually redirect dmesg output to a file or play with buffer sizes. :) Just upload that file. Cheers, Freddie Typos due to smartphone keyboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Preparing ZFS drives
On Tue, Jan 12, 2021 at 10:10 AM joe mcguckin wrote: > Folks, > > I want to buy some 16TB drives and raid them up > > How should I label and prepare the drives for ZFS? Someone ought to write > a ‘cookbook’ on that! > If these drives will be strictly data drives (not booting from them), partitioning them is fairly easy. You will want to determine a labelling system for them. Personally, I like to label the drives using a grid system (columns are letters, rows are numbers). For systems with multiple JBODs attached, I include which JBOD chassis their in as well. For example, a 24-bay chassis would use disk-a1, disk-a2, disk-a3 ... disk-d4, disk-d5, disk-d6. A system with 2 24-bay JBODs would use jbod1-a1, jbod1-a2, jbod1-a3 ... jbod2-d4, jbod2-d5, jbod2-d6. So you label the GPT partition on each disk, and build the pool using the GPT partition labels. gpart create -s gpt da0 gpart add -t freebsd-zfs -a 1M -l disk-a1 da0 gpart create -s gpt da1 gpart add -t freebsd-zfs -a 1M -l disk-a2 da1 And so on. Add 1 disk, partition/label it based on its location. Then add the next disk. And so on. Then use the GPT labels to create the pool (they show up as devices under the /dev/gpt/ directory): zpool create mypool mirror gpt/disk-a1 gpt/disk-a2 mirror gpt/disk-a3 gpt/disk-a4 mirror gpt/disk-a5 gpt/disk-a6 If you need to boot from these drives (make a root pool), then things get more complicated. Personally, I'd recommend using the 16 TB drives strictly for a data pool, and then use some smaller SSDs for a root pool, in a simple mirror vdev setup. Separate the OS from the data. :) Do I need to start the volume on a particular sector boundary? > The "-a 1M" argument for gpart does it for you. It aligns the partition at the 1 MB boundary, and figures out which sector of the disk that corresponds to based on the sector size of the disk (512B or 4K). > Are the 4096 byte sector drives usable? > Yeah, they work without issues. Try not to mix 512B and 4K drives within a single vdev (it'll work, but may cause performance issues). Mixing them in a pool (a vdev using 512B drives, another vdev using 4K drives) is okay, so long as you set the vfs.zfs.min_auto_ashift sysctl to 12 (force the minimum block size used by ZFS to be 4K). That way, in the future, you can replace the 512B drives with 4K drives without any performance issues. You can check what the ashift value is for each of the vdevs using: zdb | grep -B5 ashift If it shows ashift=9 anywhere, then destroy the pool, change the sysctl value, and recreate the pool. Check to make sure it shows ashift=12 in zdb output. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: how to use the ktls
On Mon, Jan 27, 2020 at 8:40 AM Freddie Cash wrote: > On Sun, Jan 26, 2020 at 12:08 PM Rick Macklem > wrote: > >> Oh, and for anyone out there... >> What is the easiest freebie way to test signed certificates? >> (I currently am using a self-signed certificate, but I need to test the >> "real" version >> at some point soon.) >> > > Let's Encrypt is what you are looking for. Create real, signed, > certificates, for free. They're only good for 90 days, but they are easy > to renew. There's various script and programs out there for managing Let's > Encrypt certificates (certbot, acme.sh, dehydrated, etc). There's a bunch > of different bits available in the ports tree. > > We use dehydrated at work, using DNS for authenticating the cert requests, > and have it full automated via cron, managing certs for 50-odd domains > (school servers and firewalls). Works great. > Forgot the link: https://letsencrypt.org -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: how to use the ktls
On Sun, Jan 26, 2020 at 12:08 PM Rick Macklem wrote: > Oh, and for anyone out there... > What is the easiest freebie way to test signed certificates? > (I currently am using a self-signed certificate, but I need to test the > "real" version > at some point soon.) > Let's Encrypt is what you are looking for. Create real, signed, certificates, for free. They're only good for 90 days, but they are easy to renew. There's various script and programs out there for managing Let's Encrypt certificates (certbot, acme.sh, dehydrated, etc). There's a bunch of different bits available in the ports tree. We use dehydrated at work, using DNS for authenticating the cert requests, and have it full automated via cron, managing certs for 50-odd domains (school servers and firewalls). Works great. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lockdown adaX numbers to allow booting ?
On Fri, Sep 20, 2019 at 7:35 AM Slawa Olhovchenkov wrote: > On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote: > > What about gpart output of the pool drives? > > > > In general you would create zpools using gptids or gpt labels, not the > devices, so you’re independent of device numbering. The boot loader should > only be installed on drives that contain the boot pool (maybe you have old > boot loaders on data drives?). > > ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels. > You don't worry about changed device names aroud reboots. > Very true, from ZFS' point of view. It writes a ZFS label to whichever GEOM provider you hand it (file, iSCSI device, raw device, MBR partition, GPT partition, etc), and it will find it's pool members based on those labels. ZFS doesn't care where the device is physically connected in the system, just that it is connected. But the ZFS labels aren't what it will display in "zpool list -v" or "zpool status" output. That will show the GEOM provider you gave it (and, depending on the order that GEOM tastes the devices, and what's enabled/disabled in loader.conf, that output can change). That's where it's useful to have human-readable, descriptive labels (like GPT partition labels), and to disable all the GEOM ID systems you won't be using via loader.conf. So that when things go sideways, and a disk dies, you can find it quickly and easily. Much easier to replace "gpt/jbod3-a6" in a multi-chassis storage system with 100+ drives than to figure out which bay corresponds to "ada73" after a couple of reboots that may or may not have changed the PCI bus enumeration direction, or after replacing an HBA that enumerates drives a different way (da vs ada), or after a BIOS/EFI upgrade that renumbers things, or any other number of situations. (We've run into most of these, and have come to rely on GPT partition labels for just this reason; and we stick the drive serial number on the outside of the bay, just in case). It's not a ZFS requirement. It just makes things easier for the admin down the road. Especially if the admin team changes or inherits systems. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lockdown adaX numbers to allow booting ?
On Thu, Sep 19, 2019 at 12:01 PM Andreas Nilsson wrote: > Seems like more of a bios enumeration issue. You should be able to set a > boot order better suited for your setup there. And if that does not work, > just move the sata cables around seems like the most straight forward > solution. > > Although I think I've heard it is bad practice to use raw devices for zfs, > especially if need to replace a drive, which day happens to be a different > revision, with a few fewer blocks available. Then you will not be able to > do the replace. > > Back in the good ol' days of ZFS versions where everyone was compatible with Solaris, this was an issue. However, the ondisk format (or ZFS label setup?) was changed to leave 1 MB of free space at the end of the drive to allow for this. With ZFSv6, for example, if you used a raw device for the vdev, and that disk died, and the replacement was 1 sector smaller, the replace would fail. Today, with OpenZFS, the replace would succeed. There's also 1 MB or so of reserved space in the pool such that if you fill the pool "100%", you can still do a "zfs destroy" of a dataset to free up space. Previously, this would fail, as you need space in the pool to write the metadata for the destroy before doing the destroy. ZFS of today is much more resilient to these kinds of niggles that bit us all, back in the day. :D -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lockdown adaX numbers to allow booting ?
On Thu, Sep 19, 2019 at 9:47 AM Guido Falsi wrote: > On 19/09/19 18:04, Michael Gmelin wrote: > > > > What about gpart output of the pool drives? > > > > In general you would create zpools using gptids or gpt labels, not the > devices, so you’re independent of device numbering. The boot loader should > only be installed on drives that contain the boot pool (maybe you have old > boot loaders on data drives?). > > > > Actually the installer will at least some times use the adaX device to > create ZFS pools. At least it did for me when I recently rebuilt a > machine after a (multiple) disk crash. > > So it could not be Kurt fault if he has a pool with adaX devices in it. > > I installed the system on one disk and the installed used adaX to create > the pool. I added the second disk to the mirror a few days later. > > Now I have: > > pool: zroot > state: ONLINE > scan: resilvered 24.6G in 0 days 00:09:41 with 0 errors on Tue Sep 3 > 16:10:08 2019 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0ONLINE 0 0 0 > ada0p4ONLINE 0 0 0 > gpt/zfs1 ONLINE 0 0 0 > > errors: No known data errors > > Now, in the case of a mirror (or a zraid) this could be fixed by > detaching adaX devices and reattaching them using the label. Disvantage > is the cluster will need to resilver, causing some degraded time and > extra disk load. > Boot off a LiveCD/USB stick. Export the pool. Import the pool with -d /dev/gpt and it will use the GPT labels instead. Reboot into the system, and it should continue to use the GPT labels. No resilvering required. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc script: manual stop vs system shutdown
On Thu, Aug 1, 2019, 11:15 AM Andriy Gapon, wrote: > On 01/08/2019 19:12, Warner Losh wrote: > > > > > > On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes > > mailto:freebsd-...@gndrsh.dnsmgr.net>> > > wrote: > > > > > > > > Is it possible in an rc script to distinguish between a manual stop > > > (e.g., service foo stop) and a stop during a system shutdown (via > > > rc.shutdown) ? > > > Are there any marker variables for that? > > > Or something in the global system state? > > > > Not that I can think of, but I like this idea, > > I am sure that use cases exist. > > > > > > What is the use case that needs to disambiguate the two cases... > > I have one use case in mind and it's a truly special case. > I want rc.d/watchdogd to gracefully stop watchdogd and to disable the > watchdog timer when the stop action is requested manually. And I want > it to stop watchdogd and set the watchdog timer to a special shutdown > timeout during the shutdown. If the special timeout is configured, of > course. > A horribly hackish workaround could be to do a "pgrep shutdown" and "pgrep reboot" and "pgrep halt" in the stop function of the RC script. If one of those those processes exist, then a system shutdown/reboot is in progress. Not elegant, but could be workable until something nicer is added. Cheers, Freddie Typos courtesy of my phone's keyboard. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS no longer mounted in alphanumerical order
On Mon, Mar 11, 2019 at 1:59 PM Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Mon, 11 Mar 2019 13:47-0700, Matthew Ahrens wrote: > > > On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl < > > trond.endres...@fagskolen.gjovik.no> wrote: > > > > > Has anyone else noticed ZFS datasets are no longer mounted in > > > alphanumerical order in CURRENT? It looks more like they are mounted > > > in the order in which they are encountered. > > > > Wouldn't surprise me if this was caused by the parallel mount changes. > The > > filesystems should still be mounted in hierarchical order (parents before > > children), so everything should still work. What problem are you seeing > as > > a result of the changed mount order? > > Actually no problems other than it's rather unintuitive when looking > at the output of "df -ah". Could we have a command line option for > disabling the parallel mount? > Wouldn't it make more sense to teach df, du, "zfs list", and other things that list the mounted filesystems to use sorted output? IOW, is it the mount process itself that's an issue, or just the output of mounted filesystems list? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AESNI, /dev/crypto, and new OpenSSL
On Thu, Dec 20, 2018 at 9:21 AM Alexey Dokuchaev wrote: > Had something got broken here, or I'm misunderstanding how this machinery > now works? > Start reading here: https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090195.html That thread covers this issue. :) Along with the "fix" for it. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: timing issue with ifconfig em(4) at rc.d start?
On Wed, Aug 22, 2018 at 1:25 PM Andreas Ott wrote: > Yesterday I installed a server from scratch from image > FreeBSD-12.0-ALPHA2-amd64-20180816-r337934-memstick.img, > then I updated sources with svn and did make buildworld, buildkernel, > installkernel, installworld, mergemaster. Upon reboot I can no longer > talk to the server on IPv4 but it works on IPv6, ifconfig tells me > there is no 'inet' address configured. No IPv4 inet routes are in > place either. > > If I run '/etc/rc.d/netif restart' from root shell on KVM console, I can > observe that the interface is taken down, the link light goes dark, > and then comes back up. However the "UP" log notification appears in > time *after* ifconfig attempts to apply settings to an interface > that is still down as it prints out to screen (em1 is shown there > as 'status: no carrier' at the time). > > em1: link state changed to DOWN > > > > Link state changed to up > em1: link state changed to UP > > Is there a way to delay the 'ifconfig inet' until after the link light > comes up? Or how do I force configuring an interface that's down in rc? > Nothing changed on the configuration side or the network switch > side since the original install. I also see in em(4) that the driver > has been reworked for 12.0, so maybe this is due to a code change? > > > This is running on hardware Dell R610 with a 4-port Intel PCIe NIC card > > em0@pci0:6:0:0: class=0x02 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > em1@pci0:6:0:1: class=0x02 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > em2@pci0:7:0:0: class=0x02 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > em3@pci0:7:0:1: class=0x02 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > > > $ freebsd-version -ku > 12.0-ALPHA2 > 12.0-ALPHA2 > > $uname -a > FreeBSD f-current239.sjelab.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #0 > r338153: Tue Aug 21 21:02:41 UTC 2018 r...@f-current239.sjelab.net: > /usr/obj/usr/src/amd64.amd64/sys/GENERIC > > Relevant network config bits from /etc/rc.conf > > ifconfig_em1="inet 100.79.136.239 netmask 255.255.255.0 up" > defaultrouter="100.79.136.1" > ifconfig_em1="inet6 2600:c02:b020:136::239 prefixlen 64" > ipv6_defaultrouter="2600:c02:b020:136::2" > There's nothing wrong with the timing. Your rc.conf is incorrect. The second ifconfig_em1 line overrides the former. These are variable declarations, not commands. The last setting for a variable is the only one that takes place. Either look through /etc/defaults/rc.conf for the ipv6-related entries, or switch to using an alias entry for ipv6: ifconfig_em1="inet 100.79.136.239 netmask 255.255.255.0 up" ifconfig_em1_alias0="inet6 2600:c02:b020:136::239 prefixlen 64" -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building kernel with no sound
On Mon, Jan 15, 2018 at 10:14 AM, Alexander Sieg wrote: > Hey, > i´m trying to build a custom kernel with no sound support build in. > > This is my make.conf: > MALLOC_PRODUCTION=true > KERNCONF=MYKERNEL #GENERIC-NODEBUG > DEVELOPER=yes > > and this is my kernel configuration: > include GENERIC-NODEBUG > > ident MYKERNEL > > nodevicesound # Generic sound driver (required) > nodevicesnd_es137x # Ensoniq AUdioPCI ES137x > nodevicesnd_hda # Intel High Definition Audio > nodevicesnd_ich # Intel, Nvidia and other ICH AC'97 audio > nodevicesnd_uaudio # USB Audio > nodevicesnd_via8233 # VIA VT823x Audio > > > The problem is when i try to compile it with "make buildkernel" the > build process starts, but it stop with the error that it can´t find the > header file "channel_if.h". > > /usr/src/sys/dev/sound/pcm/channel.h:256:10: fatal error: 'channel_if.h' > file not found > #include "channel_if.h" > ^~ > > The intention behind the custom kernel is to try 'oss' form the > ports tree. > You're missing a few of the sound drivers. Here's the section from GENERIC on 11.1 for sound (it's the same for 10.4 and 12-CURRENT): # Sound support device sound # Generic sound driver (required) device snd_cmi # CMedia CMI8338/CMI8738 device snd_csa # Crystal Semiconductor CS461x/428x device snd_emu10kx # Creative SoundBlaster Live! and Audigy device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_via8233 # VIA VT8233x Audio So you need to add nodevice entries for all the ones that you are missing (snd_cmi, snd_cma, snd_emu10kx). Always check the kernel config file you are including to see what you need to exclude via nodevice. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fwd: Re: USB stack
Forgot to include the list. Resending. -- Forwarded message -- From: "Freddie Cash" Date: Jan 7, 2018 12:26 AM Subject: Re: USB stack To: "blubee blubeeme" Cc: On Jan 6, 2018 8:30 PM, "blubee blubeeme" wrote: > I just connected a Transcend StorageJet 1TB hdd not a mobile phone --- Jan 7 11:56:56 blubee kernel: umass0 on uhub0 Jan 7 11:56:56 blubee kernel: umass0: on usbus0 Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Jan 7 11:56:56 blubee kernel: da0: Fixed Direct Access SPC-4 SCSI device Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 Is the slow transfers user error? You'll need to post /var/run/dmesg.boot somewhere so we can see how your USB controllers are being detected and the different buses are being configured, and which bus/controller the USB devices are attaching too. You haven't shown enough information yet to be able to help you. Cheers, Freddie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error
On Tue, Dec 12, 2017 at 2:55 PM, Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > Hum, just noticed this. 25k hours power on, 2M load cycles, this is > very hard on a hard drive. Your drive is going into power save mode > and unloading the heads. Infact at a rate of 81 times per hour? > Oh, I can not believe that. Either way we need to get this stopped, > it shall wear your drives out. > Believe it. :) The WD Green drives have a head parking timeout of 15 seconds, and no way to disable that anymore. You used to be able to boot into DOS and run the tler.exe program from WD to disable the auto-parking feature, but they removed that ability fairly quickly. The Green drives are meant to be used in systems that spend most of their time idle. Trying to use them in an always-on RAID array is just asking for trouble. They are only warrantied for a couple hundred thousand head parkings or something ridiculous like that. 2 million puts it way out of the warranty coverage. :( We had 24 of them in a ZFS pool back when they were first released as they were very inexpensive. They lead to more downtime and replacement costs than any other drive we've used since (or even before). Just don't use them in any kind of RAID array or always-on system. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error
On Tue, Dec 12, 2017 at 10:21 AM, O. Hartmann wrote: > > Question: is it possible to simply pull the faulty disk (implies I know > exactly which one > to pull!) and then prepare and add the replacement HDD and let the system > do its job > resilvering the pool? > zpool offline Do that first. That will mark the drive as offline, put the pool into a degraded mode, and generally be less harmful to the system. Then figure out which disk to pull and remove it (doing it from a powered off state if needed). Install the new drive, configure it however it's needed, then use: zpool replace > Next question is: I'm about to replace the 3 TB HDD with a more recent and > modern 4 TB > HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the > other disks are 3 > TB, but I'd like to know whether FreeBSD's ZFS is capable of handling it? > Yes, it can handle it just fine. And it will keep the extra space as "usable in the future", so if you replace all the drives with 4 TB ones, the extra space will be added to the pool. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: static routes on VLAN on CURRENT
On Jul 2, 2017 4:40 AM, "Hartmann, O." wrote: Fiddling around with a self-brewn router/firewall based on 12-CURRENT and ipfw, I run into problems when setting up a trunk port with different VLANs and static routes. The "router" has three NICs, igb0, igb1, igb2 (it is de facto an APU 2C4 from PCengines). igb0 is attached to an external VDSL2+ Modem and not connected at the moment. igb2 is also not connected yet. igb1 bears several VLANs: 2, 10, 100 (igb1.2, igb1.10 ...) and the "native", untagged LAN (on igb1). While it will sometimes work, I find that mixing tagged and untagged vlans on a single interface leads to all kinds of silent failures and issues. Just make vlan 1 tagged on that interface and the switch port. Then ignore igb1 completely, and only use the igb1.X interfaces for everything. To not use a routing daemon due to the small size of my network, I desided to use static routes, in rc.conf I placed the following variables: static_routes="igb1.2 igb1.10" route_igb1_2="-net 192.168.2.0/24 -interface igb1.2" route_igb1_10="-net 192.168.10.0/24 -interface igb1.10" You shouldn't need to add static routes as there routes will be added automatically when you assign an IP/netmask to the interface. Simplify things. Make everything tagged vlans, reduce your rc.conf to just IP assignments to the sub interfaces, and see how things work. Build it up from there. Cheers, Freddie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NO_INSTALLEXTRAKERNELS and PkgBase
On Mon, May 9, 2016 at 11:40 AM, Ultima wrote: > If multiple kernels are being installed like this, eg KERNCONF="FOO BAR", > which of the two would be default during boot? FOO because it came first? Correct. At least, that's the way it's worked in the past, and something I've used quite a bit on FreeBSD 7-9. I always have GENERIC and a custom kernel listed in KERNCONF, with my custom kernel listed first. KERNCONF="FIREWALL GENERIC" for exmaple. That way, my custom kernel is installed as /boot/kernel, and GENERIC is installed as /boot/kernel.GENERIC, which provides me with a fall-back in case I screw something up with my custom kernel (happens frequently). :) I used to do it manually using two separate installkernel steps using an env var to specify the installation directory (/boot/GENERIC) (forget the name of that var right now), but switched to using the automatic installation behaviour when it became available. Simplified things a bit. I haven't compiled a kernel on 10+ yet; hopefully the behaviour hasn't changed. ;) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot loaders got fatter in the last few days
On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer wrote: > On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude > wrote: > > On 2016-03-18 12:33, Guido Falsi wrote: > >> > >> Hi, > >> > >> I have just update one of my machines and noticed the booloaders files > >> got quite fat in the last few days, some by a big margin. > >> > >> on an updated machine(r296993): > >> > >> -r--r--r-- 1 root wheel 85794 Mar 18 16:47 /boot/gptboot > >> > >> from a machine I still have not updated(r296719): > >> > >> -r--r--r-- 1 root wheel 16059 Mar 13 21:01 /boot/gptboot > > So the loader grew 70 kB. How big are your disks? > > >> I noticed because mu gpt boot partition is 64K and gptzfsboot just > >> passed 100K. > > > > This is a side effect of the loader gaining the ability to boot from GELI > > encrypted partitions. > > > > ... > > > > Maybe we should be putting the GELI enabled boot blocks in a different > > filename? I generally wanted to avoid creating a new version of each > > bootcode with GELI support. > > > I think we should just suggest that boot partitions be much larger > than 64kB (1MB is still <0.1% of any disk sold today) and not worry > about it too much. Embedded applications can disable GELI loader > support to save a few bytes. > The boot partition doesn't necessarily need to be 1 MB (and can't due to some issues with the assembler used right now, or something like that). We just need to make sure people have slack space in their partition table to expand into in the future. Using "-a 1M" in your gpart command to create your first data partition gives you that slack space. gpart create -s gpt ada0 gpart add -t freebsd-boot -s 256K -l boot ada0 gpart add -t freebsd-ufs -s 10G -l root -a 1M ada0 That leaves ~756 KB of free space between the end of the boot partition and the start of the first data partition. Increasing the size of the boot partition in the future is as easy as (no formatting of disks required): gpart delete -i 1 ada0 gpart add -t freebsd-boot -s 512K -l boot ada0 gpart bootcode -b ... -p ... ada0 It's a handy pattern I've gotten used to over the years, ever since the first 4K sector harddrives were advertised (as alignment of filesystems was/is *very* important). Even on disks that will be used solely for ZFS I've taken to creating GPT partitions starting at 1 MB. And it's saved me from having to reformat disks when moving from a separate root filesystem (no USB sticks) to root-on-ZFS as there was 1 MB of free space at the start of every disk for creating boot partitions. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot loaders got fatter in the last few days
On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude wrote: > On 2016-03-18 17:41, Freddie Cash wrote: > >> >> On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer > <mailto:c...@freebsd.org>> wrote: >> >> On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude > <mailto:allanj...@freebsd.org>> wrote: >> > On 2016-03-18 12:33, Guido Falsi wrote: >> >> >> >> Hi, >> >> >> >> I have just update one of my machines and noticed the booloaders >> files >> >> got quite fat in the last few days, some by a big margin. >> >> >> >> on an updated machine(r296993): >> >> >> >> -r--r--r-- 1 root wheel 85794 Mar 18 16:47 /boot/gptboot >> >> >> >> from a machine I still have not updated(r296719): >> >> >> >> -r--r--r-- 1 root wheel 16059 Mar 13 21:01 /boot/gptboot >> >> So the loader grew 70 kB. How big are your disks? >> >> >> I noticed because mu gpt boot partition is 64K and gptzfsboot just >> >> passed 100K. >> > >> > This is a side effect of the loader gaining the ability to boot >> from GELI >> > encrypted partitions. >> > >> > ... >> > >> > Maybe we should be putting the GELI enabled boot blocks in a >> different >> > filename? I generally wanted to avoid creating a new version of >> each >> > bootcode with GELI support. >> >> >> I think we should just suggest that boot partitions be much larger >> than 64kB (1MB is still <0.1% of any disk sold today) and not worry >> about it too much. Embedded applications can disable GELI loader >> support to save a few bytes. >> >> >> The boot partition doesn't necessarily need >> to be 1 MB (and can't due to some issues with the assembler used right >> now, or something like that). We just need to make sure people have >> slack space in their partition table to expand into in the future. >> >> Using "-a 1M" in your gpart command to create your first data partition >> gives you that slack space. >> >> gpart create -s gpt ada0 >> gpart add -t freebsd-boot -s 256K -l boot ada0 >> gpart add -t freebsd-ufs -s 10G -l root -a 1M ada0 >> >> That leaves ~756 KB of free space between the end of the boot partition >> and the start of the first data partition. Increasing the size of the >> boot partition in the future is as easy as (no formatting of disks >> required): >> >> gpart delete -i 1 ada0 >> gpart add -t freebsd-boot -s 512K -l boot ada0 >> gpart bootcode -b ... -p ... ada0 >> >> It's a handy pattern I've gotten used to over the years, ever since the >> first 4K sector harddrives were advertised (as alignment of filesystems >> was/is *very* important). >> >> Even on disks that will be used solely for ZFS I've taken to creating >> GPT partitions starting at 1 MB. And it's saved me from having to >> reformat disks when moving from a separate root filesystem (no USB >> sticks) to root-on-ZFS as there was 1 MB of free space at the start of >> every disk for creating boot partitions. :) >> >> -- >> Freddie Cash >> fjwc...@gmail.com <mailto:fjwc...@gmail.com> >> > > This also has the handy side effect of allowing you to switch to booting > with UEFI, which currently uses an 800kb fat file system And I'm pretty sure I read somewhere that the 10.x installer defaults to using "-a 1M" when partitioning new disks, although I haven't installed any 10.x systems from scratch yet (just upgrades from 9.x). -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfsboot patch for /usr
On Mar 9, 2016 4:04 PM, "Miroslav Lachman" <000.f...@quip.cz> wrote: > > Roger Marquis wrote on 03/10/2016 00:36: >> >> Wondering if anyone has example patches for zfsboot (from >> usr.sbin/bsdinstall/scripts)? >> >> We're looking to change some of the default zfs subvolumes, removing /usr in >> favor of /usr/local in particular, and have run into a "parent does not exist" >> issue. It's not clear where in the script the /usr parent dir should be >> mkdir'd. > > > I no nothing about this script but if you want /usr/local as ZFS filesystem, then you need to create parent (/usr in this case) and you can use property canmount=off plus different 'mountpoint' (for example /mnt/usr) to not mount /usr over existing directory on root filesystem. Set mountpoint=none if you just want to create the parent dataset without actually using it for storage. Then you can set properties on it, and child datasets will inherit then. Like pool/usr/local You'd still need to "mkdir /usr" in the script, but that's separate. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Buildworld ccache support
On Tue, Oct 20, 2015 at 6:32 AM, Juan Ramón Molina Menor wrote: > Hi! > > I’m certainly doing it wrong, because CCACHE does not kick in after > applying the patch and modifying make.conf. CCACHE stats ('ccache -z' > followed by 'ccache -s') remain at zero during buildworld while they used > to reflect the cache miss/hits before. > > # cat /etc/make.conf > WITH_CCACHE_BUILD= > You need to actually set this to a value, in order for the variable to be defined. WITH_CCACHE_BUILD=yes WITH_CCACHE_BUILD=something WITH_CCACHE_BUILD=whatever It doesn't matter what it's set to, but it has to be set to something. > > # svn diff /usr/src/share/mk/local.init.mk > Index: /usr/src/share/mk/local.init.mk > === > --- /usr/src/share/mk/local.init.mk (revision 289627) > +++ /usr/src/share/mk/local.init.mk (working copy) > @@ -38,3 +38,37 @@ > HOST_CFLAGS+= -DHOSTPROG > CFLAGS+= ${HOST_CFLAGS} > .endif > + > +# Handle ccache after CC is determined. If CC is at some specific path > then > +# we must prepend the ccache wrapper. Otherwise we can just prepend PATH > with > +# the wrapper location, which is a more safe solution since it avoids > spaces > +# and compiler type guessing based on filename. > +LOCALBASE?=/usr/local > +CCACHE_WRAPPER_PATH?= ${LOCALBASE}/libexec/ccache > +CCACHE_PATH?= ${LOCALBASE}/bin/ccache > +.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \ > This line here checks if the variable is defined (meaning, that it is set to something), and if it is, then the code after it enabled CCACHE. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: init(8) diagnostics?
On Nov 16, 2014 10:07 AM, "Steve Kargl" wrote: > > In init(8), one finds under DIAGNOSISTICS > >"some processes would not die; ps axl advised." > > So, just how is one to actually run 'ps axl advised' as > the message appears as init(8) is killing off the system? "shutdown now" will drop you to single-user mode with a running shell where you can run that command to see what hasn't been stopped. IIRC, that message appears right before you drop to the shell, although I haven't run it a long time, so going by memory. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg 1.4 freeze please test test test!
On Mon, Nov 3, 2014 at 1:40 PM, Hans Petter Selasky wrote: > Is it possible when upgrading a system via "pkg" to selectivly switch > upgrades ON/OFF. For example I have a custom ffmpeg install and would like > to keep it every time I do a binary upgrade? > # man pkg-lock ;) I believe that's what you are looking for. No idea how well it works long-term, though, or if you lock a large number of packages. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ssh None cipher
On Sat, Oct 18, 2014 at 12:32 PM, Allan Jude wrote: > On 2014-10-18 13:21, Freddie Cash wrote: > > On Oct 18, 2014 3:54 AM, "Mark Martinec" > > wrote: > >> > >> If the purpose of having a none cipher is to have a fast > >> file transfer, then one should be using sysutils/bbcp > >> for that purposes. Uses ssd for authentication, and > >> opens unencrypted channel(s) for the actual data transfer. > >> It's also very fast, can use multiple TCP streams. > > > > That's an interesting alternative to rsync, scp, and ftp, but doesn't > help > > with zfs send/recv which is where the none cipher really shines. > > > > Without the none cipher, SSH becomes the bottleneck limiting transfers to > > around 400 Mbps on a gigabit LAN. With the none cipher, the network > becomes > > the bottleneck limiting transfers to around 920 Mbps on the same gigabit > > LAN. > > > > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. > > Actually, looking into it, the bbcp command can support a pipe at each > end instead of files, so you can actually do a zfs send | zfs receive > via bbcp, and use multiple concurrent connections, to get around TCP > window stuff when going transatlantic > > I am going to be trying it out shortly. > > Note: the other big improvement in newer ssh is the HPN stuff, that is > switched on since 9.2 I think. After much finagling and testing, I have managed to incorporate bbcp into my ZFS send/recv script. And it works much better than regular, encrypted SSH in my setup. Regular SSH transfers tended to top out around 400 Mbps, using 100% of 1 CPU. Was not able to get the multi-threadded AES cipher working. SSH connections using the NONE cipher saturated the gigabit link with minimal CPU usage. And a bbcp connection is currently running between 500-800 Mbps (depending on the size of the snpashot), also with minimal CPU usage. NOTE: I expect this be running much better next week, as the receiving pool is currently resilvering a drive, slowing everything down. Got things working using the following bbcp command format: bbcp -N io "zfs send -I pool/fs@snap1 pool/fs@snap2" username@remotesys:"zfs recv -d pool" Have not played with any of the myriad tuning options for bbcp. Just wanted to see if I could get it to work, and how an untuned connection compared to an untuned SSH connection (with and without NONE cipher). So far, I'm impressed. Thanks for the suggestion. It's another tool in the box. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ssh None cipher
On Sun, Oct 19, 2014 at 10:35 AM, Freddie Cash wrote: > On Oct 19, 2014 12:46 AM, "John-Mark Gurney" wrote: > > > > Freddie Cash wrote this message on Sat, Oct 18, 2014 at 10:21 -0700: > > > On Oct 18, 2014 3:54 AM, "Mark Martinec" > > > > wrote: > > > > > > > > If the purpose of having a none cipher is to have a fast > > > > file transfer, then one should be using sysutils/bbcp > > > > for that purposes. Uses ssd for authentication, and > > > > opens unencrypted channel(s) for the actual data transfer. > > > > It's also very fast, can use multiple TCP streams. > > > > > > That's an interesting alternative to rsync, scp, and ftp, but doesn't > help > > > with zfs send/recv which is where the none cipher really shines. > > > > > > Without the none cipher, SSH becomes the bottleneck limiting transfers > to > > > around 400 Mbps on a gigabit LAN. With the none cipher, the network > becomes > > > the bottleneck limiting transfers to around 920 Mbps on the same > gigabit > > > LAN. > > > > > > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. > > > > Are you running on HEAD or possibly 10.x (I believe we have OpenSSL > > 1.0.x on 10.x)? > > Nope, 9.2. And I don't think the 6200 series Opterons have AES-NI. > Correction, the AMD Opteron 6200-series of CPUs to support AES-NI. However, these storage boxes use AMD Opteron 6128 CPUs. :( They do not support AES-NI. AES-based ciphers are extremely slow on these systems; the multithreaded AES-based ciphers are better, but nowhere near what the NONE cipher provides. :) sysutils/bbcp is interesting as an alternative, but it's a lot more complex than just enabling NONE in OpenSSH. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ssh None cipher
On Oct 19, 2014 12:46 AM, "John-Mark Gurney" wrote: > > Freddie Cash wrote this message on Sat, Oct 18, 2014 at 10:21 -0700: > > On Oct 18, 2014 3:54 AM, "Mark Martinec" > > wrote: > > > > > > If the purpose of having a none cipher is to have a fast > > > file transfer, then one should be using sysutils/bbcp > > > for that purposes. Uses ssd for authentication, and > > > opens unencrypted channel(s) for the actual data transfer. > > > It's also very fast, can use multiple TCP streams. > > > > That's an interesting alternative to rsync, scp, and ftp, but doesn't help > > with zfs send/recv which is where the none cipher really shines. > > > > Without the none cipher, SSH becomes the bottleneck limiting transfers to > > around 400 Mbps on a gigabit LAN. With the none cipher, the network becomes > > the bottleneck limiting transfers to around 920 Mbps on the same gigabit > > LAN. > > > > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. > > Are you running on HEAD or possibly 10.x (I believe we have OpenSSL > 1.0.x on 10.x)? Nope, 9.2. And I don't think the 6200 series Opterons have AES-NI. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ssh None cipher
On Oct 18, 2014 3:54 AM, "Mark Martinec" wrote: > > If the purpose of having a none cipher is to have a fast > file transfer, then one should be using sysutils/bbcp > for that purposes. Uses ssd for authentication, and > opens unencrypted channel(s) for the actual data transfer. > It's also very fast, can use multiple TCP streams. That's an interesting alternative to rsync, scp, and ftp, but doesn't help with zfs send/recv which is where the none cipher really shines. Without the none cipher, SSH becomes the bottleneck limiting transfers to around 400 Mbps on a gigabit LAN. With the none cipher, the network becomes the bottleneck limiting transfers to around 920 Mbps on the same gigabit LAN. This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD
On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella < stefanogarzare...@gmail.com> wrote: > I saw the discussion about TSO, but the GSO is a software > implementation unrelated with the hardware. > Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is > not executed, because is useless. > > After the execution of the GSO, the packets, that are passed to the device > driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For > this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardware > segment limits. > > The GSO is very useful when you can't use the TSO. > How does GSO affect IPFW, specifically the libalias(3)-based, in-kernel NAT? The ipfw(8) man page mentions that it doesn't play nicely with hardware-based TSO, and that one should disable TSO when using IPFW NAT. Will the software-based GSO play nicely with IPFW NAT? Will it make any difference to packet throughput through IPFW? Or is it still way too early in development to be worrying about such things? :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Import of DragonFly Mail Agent
On Feb 24, 2014 7:50 AM, "Lyndon Nerenberg" wrote: > > > On Feb 24, 2014, at 7:40 AM, Bryan Drewery wrote: > > > Anything not meeting the bare-bones criteria can be installed with 'pkg > > install' or ports. > > Try this in a shop where all your machines are completely air-gapped from the internet. Install from DVD which includes the vast majority of packages built from the ports tree. If you have a way to install FreeBSD, you have a way to get software onto it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libinit idea
Typos and terseness brought to you by the LG G2 running SlimKat. On Feb 23, 2014 10:22 AM, "Lucius Rizzo" wrote: > > * Andreas Nilsson [2014-02-23 09:33]: > > Imho, the replacement to init and rc-scripts I sometimes think about > > would be to import SMF from opensolaris/illumos. There one can at > > least get the commands run and config used without looking at the > > source code. > > I like SMF from Solaris 11 onwards and even SmartOS. However, I have > found to like systemd and use via systemctl on Arch far nicer than any > other rc scripts to date. > > Anyone care to share their thoughts on the pros and cons of something > like systemd the way Arch does? The main developer for systemd is very anti-portability and anti-!Linux. He had actively rejected patches that made his projects work on non-Linux systems. In order to port systemd to a non-Linux system, he wants you to first implement every Linux feature that systemd uses. systemd is a non-starter, and not with considering. In theory, devd could be extended to support socket-activation, and the support for that added to RCng, providing the bulk of the systemd features, without having to deal with the systemd devs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error message from pkg on HEAD
On Mon, Jan 13, 2014 at 8:22 PM, Glen Barber wrote: > On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote: > > So, now when I run pkg I get the following: > > pkg: Ignoring bad configuration entry in > /usr/local/etc/pkg/repos/FreeBSD.conf: "URL: > http://pkg.freebsd.org/${ABI}/latest"; > > pkg: Ignoring bad configuration entry in > /usr/local/etc/pkg/repos/FreeBSD.conf: true > > pkg: Ignoring bad configuration entry in > /usr/local/etc/pkg/repos/FreeBSD.conf: "SRV" > > > > pkg does seem to work so I'm not sure what I need to do. I think I was > > told to add these lines to the file, though I'm not sure, so I don't want > > to delete them. > > > > Thanks for help in letting me know what the solution is. > > > > # pkg -v > > 1.2.4_1 > > # uname -a > > FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 > r260082M: Wed Jan 1 12:08:41 PST 2014 > j...@carbon.funkthat.com:/usr/obj/usr/src/sys/lockprof > amd64 > > # cat /usr/local/etc/pkg/repos/FreeBSD.conf > > FreeBSD: > > URL: http://pkg.freebsd.org/${ABI}/latest > > ENABLED: YES > > MIRROR_TYPE: SRV > > > > The file format is incorrect. > > FreeBSD: { > url: "http://pkg.freebsd.org/${ABI}/latest";, > enabled: yes, > mirror_type: "srv" > } > > Shouldn't the URL start with "pkg+http://"? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn && ports, or the hen && egg
On Wed, Dec 18, 2013 at 1:09 PM, Matthias Apitz wrote: > El día Wednesday, December 18, 2013 a las 12:59:16PM -0800, Freddie Cash > escribió: > > > On Wed, Dec 18, 2013 at 12:50 PM, Matthias Apitz > wrote: > > > > > As ports are now for some time are to be pulled out via SVN (and not > > > CVS) and the svn client is only in the ports tree and not in the base > > > system, how is this thought to work in a clean way, without dusting the > > > system before with some binary packages, only based on base system and > > > sources? > > > > > > svnlite is included in the base OS for 10.0. > > > > See https://wiki.freebsd.org/WhatsNew/FreeBSD10 for details. And > > http://svnweb.freebsd.org/base?view=revision&revision=251886 for the > commit > > message. > > Ok, thanks; but see this: > > $ uname -a > FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 > 12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC/i386 > $ svnlite > Type 'svn help' for usage. > $ svn help > svn: not found > And ... if you type "svnlite help" what happens? The name of the command is svnlite, not svn, so you may have to mentally swap the terms in terminal messages. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn && ports, or the hen && egg
On Wed, Dec 18, 2013 at 12:50 PM, Matthias Apitz wrote: > As ports are now for some time are to be pulled out via SVN (and not > CVS) and the svn client is only in the ports tree and not in the base > system, how is this thought to work in a clean way, without dusting the > system before with some binary packages, only based on base system and > sources? > > svnlite is included in the base OS for 10.0. See https://wiki.freebsd.org/WhatsNew/FreeBSD10 for details. And http://svnweb.freebsd.org/base?view=revision&revision=251886 for the commit message. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official FreeBSD Binary Packages now available for pkgng
On Thu, Oct 31, 2013 at 3:15 PM, Eric Camachat wrote: > browsing www.freebsd.org worked fine. > tried pkg.freebsd.org it got below. > Our DNS server can resolve proxy server only. > Only proxy server can resolve internet sites, this is how our company force > all traffic went through proxy server. > > Eric > > Network Error (dns_server_failure) > > Your request could not be processed because an error occurred contacting > the DNS server. The DNS server may be temporarily unavailable, or there > could be a network problem. > If problem persists, please open a ticket with Motorola help desk; and copy > and paste this page in ticket. > > Date/Time: 2013-10-31 22:11:37 Request: GET http://pkg.freebsd.org/ Error: > (dns_server_failure) Proxy Name:proxy > Proxy IP: xxx.xxx.xxx.xxx Client IP: zzz.zzz.zzz.zzz > Referer URL: > So, then manually specific a specific pkg mirror and by-pass the DNS SRV record resolution step. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] libdispatch (aka Grand Central Dispatch) in base
On Oct 29, 2013 7:21 PM, "Teske, Devin" wrote: > > > On Oct 29, 2013, at 7:17 PM, Freddie Cash wrote: > > > > > On Oct 29, 2013 7:07 PM, "Teske, Devin" wrote: > > > > > > Hi all, > > > > > > I'd like to bring up the discussion for topic.. > > > > > > Importing libdispatch (aka Apple's Grand Central Dispatch) into base (contrib?). > > > > Hasn't this been done already? There's mention of it in the archives from 2009/2010. There was a port by Robert Watson et al to 8.1 mentioned in the quarterly status reports, and indications it would be imported after 8.1-release. > > > > I knew about the port, and I had heard about previous efforts, but when I go > scrounging around HEAD, I can't find it. Let alone older branches. Hrm, maybe it hasn't been imported yet (Google search of svnweb.FreeBSD.orgonly shows the ports branch). And looks like the port hasn't been touched in 2 years. I just remembered reading about it and found the quarterly report in my mail archive. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] libdispatch (aka Grand Central Dispatch) in base
On Oct 29, 2013 7:07 PM, "Teske, Devin" wrote: > > Hi all, > > I'd like to bring up the discussion for topic.. > > Importing libdispatch (aka Apple's Grand Central Dispatch) into base (contrib?). Hasn't this been done already? There's mention of it in the archives from 2009/2010. There was a port by Robert Watson et al to 8.1 mentioned in the quarterly status reports, and indications it would be imported after 8.1-release. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fwd: Re: ZFS buggy in CURRENT? Stuck in [zio->io_cv] forever!
Forgot to include the list in reply. -- Forwarded message -- From: "Freddie Cash" Date: Oct 27, 2013 10:36 AM Subject: Re: ZFS buggy in CURRENT? Stuck in [zio->io_cv] forever! To: "O. Hartmann" Cc: Did your recv complete before you exported the pool? If not, then the import will "hang" until it has deleted three hidden clone dataset for the aborted receive. Once all the blocks are freed successfully, then the import will complete and the pool well be usable again. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs
On Wed, Oct 9, 2013 at 9:12 AM, Freddie Cash wrote: > On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer wrote: > >> On 10/9/13 2:35 AM, Freddie Cash wrote: >> >>> On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein wrote: >>> >>> You're right on the money, to be honest this is one of the reasons why >>>> I've switched to using OSX as my desktop OS. >>>> >>>> zsh, vim, screen by default. and upgrades work. At the end of the day >>>> I'm spending time doing work, not mucking about my workspace to make it >>>> usable for development. >>>> >>>> I think this was brought up at BSDCan in the discussion about making >>>> FreeBSD a more featured development platform. >>>> >>>> Speaking of... has anyone tried PCBSD? >>>> >>> >>> PC-BSD isn't much different from FreeBSD. The installer is GUI and >>> support >>> ZFS, there are some GUI setup tools on first boot for X, there are some >>> GUI >>> tools to select binary drivers for X, and there are working pkgng repos >>> available. >>> >>> I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do >>> things >>> "the FreeBSD way" which broke a lot of things that were done "the PC-BSD >>> way" (aka don't manually edit config files used for booting). >>> >>> Switching to the "rolling-release" (aka PC-BSD 9-STABLE) and moving all >>> my >>> config file edits into .conf.local fixed my issues. Things >>> have >>> been running smooth, and I finally understand the beauty and simplicity >>> of >>> freebsd-update + pkg. OS gets updated once per month, packages get >>> updated >>> twice per month, no more compiling things from source. It's like using >>> Ubuntu/Debian but with the power and features of FreeBSD. :) >>> >>> >> >> When they went to a ZFS-only system, using GRUB, with no alternative, >> then I'm afraid they lost me. >> I want a root filesystem on UFS for reliabailty and simpleness. I can >> debug it's media if needed. >> Before then I really liked it (though ther eis not enough information on >> how it works interneally if you want to use it. >> hopefully that will come.. and I LIKE PBIs FreeBSD should adopt PBIs for >> sure. >> With PBIs you could make even quite base items separately installable. >> versioning problems go away. >> > > There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2. Even on > a ZFS-only setup (which is what I run). It's using the FreeBSD loader, > with custom artwork and menus. > Hrm, it seems they've changed things with the 9.2 installer. It does use GRUB2 (e!) for the boot loader, and integrates support for ZFS boot environments (via beadm) into it. :( Shame they didn't use the BE support in the FreeBSD loader for this. Wonder if my 9-STABLE-based PC-BSD install will get "upgraded" to GRUB? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs
On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer wrote: > On 10/9/13 2:35 AM, Freddie Cash wrote: > >> On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein wrote: >> >> You're right on the money, to be honest this is one of the reasons why >>> I've switched to using OSX as my desktop OS. >>> >>> zsh, vim, screen by default. and upgrades work. At the end of the day >>> I'm spending time doing work, not mucking about my workspace to make it >>> usable for development. >>> >>> I think this was brought up at BSDCan in the discussion about making >>> FreeBSD a more featured development platform. >>> >>> Speaking of... has anyone tried PCBSD? >>> >> >> PC-BSD isn't much different from FreeBSD. The installer is GUI and >> support >> ZFS, there are some GUI setup tools on first boot for X, there are some >> GUI >> tools to select binary drivers for X, and there are working pkgng repos >> available. >> >> I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do things >> "the FreeBSD way" which broke a lot of things that were done "the PC-BSD >> way" (aka don't manually edit config files used for booting). >> >> Switching to the "rolling-release" (aka PC-BSD 9-STABLE) and moving all >> my >> config file edits into .conf.local fixed my issues. Things have >> been running smooth, and I finally understand the beauty and simplicity of >> freebsd-update + pkg. OS gets updated once per month, packages get >> updated >> twice per month, no more compiling things from source. It's like using >> Ubuntu/Debian but with the power and features of FreeBSD. :) >> >> > > When they went to a ZFS-only system, using GRUB, with no alternative, then > I'm afraid they lost me. > I want a root filesystem on UFS for reliabailty and simpleness. I can > debug it's media if needed. > Before then I really liked it (though ther eis not enough information on > how it works interneally if you want to use it. > hopefully that will come.. and I LIKE PBIs FreeBSD should adopt PBIs for > sure. > With PBIs you could make even quite base items separately installable. > versioning problems go away. > There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2. Even on a ZFS-only setup (which is what I run). It's using the FreeBSD loader, with custom artwork and menus. There's also nothing stopping you from installing / onto UFS. At least, I didn't see anything that would prevent it when I installed it originally. Granted, that was with 9.1, so the installer may be different in 9.2. I tried to use PBIs, but really messed up the system doing so. /usr was just a directory on /, on a USB stick, and ran out of room. Tried various things to get it off / and b0rked the system. Even after moving to ZFS-on-root and getting away from filesystem limits, I still couldn't get PBIs to upgrade properly. Since moving away from PBIs, away from ports, away from pkg_* tools, and sticking strictly with pkg, everything has been running smoothly. The experience with pkg on PC-BSD gives me hope for FreeBSD again (too many issues in the past with ports and pkg_* tools, even when using only portmaster). For desktops, a binary-only system using freebsd-update and pkg is so much nicer. For servers, implementing your own freebsd-update server and pkg repo (via poudriere) is so much nicer. If I never have to compile a port on a remote system again, I will be a happy man. :) To each their own, of course. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn wrote: > 4. What is this gnop stuff for? > Can't comment on the rest, but gnop is required to create 4K-aligned vdevs where the minimum block size is 4K (aka ashift=12). Without this, ZFS relies on the underlying disk driver providing the correct information, and most don't. Also, if you don't do this, and create a vdev using 512B sectors, the ashift will be set to 9, and replacing the drive down the line with 4K Advanced Format drive will drop your drive performance in the toilet. Thus, to future-proof your pool, you need to: - set the ashift of the pool to 12 (4 KB) - align the disk/partition on 4 KB boundaries (starting partition at 1 MB works well) Until our ZFS gains the ability to set a minimum ashift for the pool, or to set the ashift at vdev creation, or all drive manufacturers write perfect firmware, than we need to fake it with gnop. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs
On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein wrote: > You're right on the money, to be honest this is one of the reasons why > I've switched to using OSX as my desktop OS. > > zsh, vim, screen by default. and upgrades work. At the end of the day > I'm spending time doing work, not mucking about my workspace to make it > usable for development. > > I think this was brought up at BSDCan in the discussion about making > FreeBSD a more featured development platform. > > Speaking of... has anyone tried PCBSD? PC-BSD isn't much different from FreeBSD. The installer is GUI and support ZFS, there are some GUI setup tools on first boot for X, there are some GUI tools to select binary drivers for X, and there are working pkgng repos available. I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do things "the FreeBSD way" which broke a lot of things that were done "the PC-BSD way" (aka don't manually edit config files used for booting). Switching to the "rolling-release" (aka PC-BSD 9-STABLE) and moving all my config file edits into .conf.local fixed my issues. Things have been running smooth, and I finally understand the beauty and simplicity of freebsd-update + pkg. OS gets updated once per month, packages get updated twice per month, no more compiling things from source. It's like using Ubuntu/Debian but with the power and features of FreeBSD. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs
On Tue, Oct 8, 2013 at 7:09 AM, Alfred Perlstein wrote: > On 10/7/13 9:49 PM, Julian Elischer wrote: > >> On 10/8/13 11:19 AM, Lyndon Nerenberg wrote: >> >>> On 2013-10-07, at 8:15 PM, Steve Kargl >> edu > wrote: >>> >>> Maybe there was no development for 15 years. However, the 7364 >>>> lines in ChangeLog after 2010-02-04 suggests that there may >>>> be few bugs to worry about. >>>> >>> >> I think the fact is that most direct users of RCS use it in a very simple >> way, and >> it works just fine for that. with no real need for any updates or any >> change. >> > > With all due respect Julian, The more we discuss this more this really > points to the problem that FreeBSD appears to be a challenge to install > packages into such that a package moving out of base is such a big deal. > > Can we fix that instead? > > I mean, this change should really not be a big deal, but yet it is and > this speaks to the core of FreeBSD utility. > > So again, is there a way to make it so adding RCS after install is not a > big deal at all? I haven't kept up-to-date with all the developments, but isn't this part of the bsdinstall/pkgng plan? Once the pkgng repos are all available and populated, then bsdinstall will be able to install packages from there during the install. And, isn't that part of the plan for the DVD installers, to include an "installer repo" for off-line installs? IOW, theoretically, one could just download the 10.0 DVD, boot, install the base, browse the repo on the DVD, select items to install, install, reboot, and be finished. Without ever needing to touch an Internet connection until after rebooting into FreeBSD, if it's even needed at all. Or was that one of the "pie-in-the-sky" ideas that hasn't materialised yet? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On Mon, Oct 7, 2013 at 2:47 PM, Igor Mozolevsky wrote: > On 7 October 2013 22:28, Lev Serebryakov wrote: > > svnlite? :) > > > > Thanks Lev & Glen- it's something to explore albeit that screws up quite a > lot of stuff on this end... > Why does that screw up anything? Just include the RCS package on your install media, and add "pkg_add /path/to/rcs.tgz" or "pkg add /path/to/rcs.txz" to the end of your install script. 1 extra tarball, 1 extra line in your install script, and everything carries on as before. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: compilation
umass requires SCSI support. Bert you removed scbus, da, and similar. On 2013-07-27 6:00 PM, "gahn" wrote: > hi all: > > need your experts' opinions, i tried to compile customized kernel for 8.3 > but failed miserably: > > linking kernel.debug > dcons_crom.o(.text+0x388): In function `dcons_crom_post_busreset': > /usr/src/sys/dev/dcons/dcons_crom.c:145: undefined reference to > `crom_add_chunk' > dcons_crom.o(.text+0x3a0):/usr/src/sys/dev/dcons/dcons_crom.c:146: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x3be):/usr/src/sys/dev/dcons/dcons_crom.c:147: > undefined reference to `crom_add_simple_text' > dcons_crom.o(.text+0x3d6):/usr/src/sys/dev/dcons/dcons_crom.c:148: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x3f7):/usr/src/sys/dev/dcons/dcons_crom.c:149: > undefined reference to `crom_add_simple_text' > dcons_crom.o(.text+0x412):/usr/src/sys/dev/dcons/dcons_crom.c:150: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x430):/usr/src/sys/dev/dcons/dcons_crom.c:151: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x467):/usr/src/sys/dev/dcons/dcons_crom.c:128: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x485):/usr/src/sys/dev/dcons/dcons_crom.c:129: > undefined reference to `crom_add_entry' > umass.o(.text+0xf9): In function `umass_detach': > /usr/src/sys/dev/usb/storage/umass.c:2180: undefined reference to > `xpt_bus_deregister' > umass.o(.text+0x120):/usr/src/sys/dev/usb/storage/umass.c:2183: undefined > reference to `cam_sim_free' > umass.o(.text+0xcfd): In function `umass_std_transform': > /usr/src/sys/dev/usb/storage/umass.c:3018: undefined reference to > `xpt_done' > umass.o(.text+0xd1c):/usr/src/sys/dev/usb/storage/umass.c:3022: undefined > reference to `xpt_done' > umass.o(.text+0xd8a): In function `umass_cam_quirk_cb': > /usr/src/sys/dev/usb/storage/umass.c:2733: undefined reference to > `xpt_done' > umass.o(.text+0xe13): In function `umass_command_start': > /usr/src/sys/dev/usb/storage/umass.c:1611: undefined reference to > `xpt_done' > umass.o(.text+0xf48): In function `umass_cam_sense_cb': > /usr/src/sys/dev/usb/storage/umass.c:2707: undefined reference to > `xpt_done' > umass.o(.text+0xf92):/usr/src/sys/dev/usb/storage/umass.c:2714: more > undefined references to `xpt_done' follow > umass.o(.text+0x245e): In function `umass_cam_action': > /usr/src/sys/dev/usb/storage/umass.c:2497: undefined reference to > `cam_calc_geometry' > umass.o(.text+0x2466):/usr/src/sys/dev/usb/storage/umass.c:2498: undefined > reference to `xpt_done' > umass.o(.text+0x24d2):/usr/src/sys/dev/usb/storage/umass.c:2508: undefined > reference to `xpt_done' > umass.o(.text+0x2556):/usr/src/sys/dev/usb/storage/umass.c:2518: undefined > reference to `xpt_done' > umass.o(.text+0x2d86): In function `umass_attach': > /usr/src/sys/dev/usb/storage/umass.c:2115: undefined reference to > `cam_simq_alloc' > umass.o(.text+0x2dd5):/usr/src/sys/dev/usb/storage/umass.c:2119: undefined > reference to `cam_sim_alloc' > umass.o(.text+0x2de7):/usr/src/sys/dev/usb/storage/umass.c:2132: undefined > reference to `cam_simq_free' > umass.o(.text+0x2e4c):/usr/src/sys/dev/usb/storage/umass.c:2141: undefined > reference to `xpt_bus_register' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/giraffe. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > > any help would be greatly appreciated. > > _dave > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: expanding past 1 TB on amd64
On Wed, Jul 17, 2013 at 7:50 AM, Bob Bishop wrote: > Hi, > > On 17 Jul 2013, at 15:17, Kurt Lidl wrote: > > >> On 7/16/2013 2:12 PM, Alan Cox wrote: > >>> ... The Haswell line of CPUs is widely reported to > >>>> support DIMMs twice as large, and it's due in September. That would > >>>> make the systems of late 2013 hold up to 1536GB of memory. > >> > >> I'd point you at stuff like the Supermicro X8BQ6 series of mainboards. > >> QP E5-8800 systems with 1 TB of memory have been around since 2011. > > > > That might have been true, but I did check SuperMicro's > > "motherboard matrix" of available products before posting. > > > > The largest listed memory configuration on > > any of their current products is 768GB. > > > > > http://www.supermicro.com/products/motherboard/matrix/?cpuclass=all&sorton=memory > > > > -Kurt > > http://www.supermicro.com/products/motherboard/Xeon7000 > > Looks like their matrix is not up-to-date. There's also several AMD motherboards that support 1 TB of RAM: http://www.supermicro.com/products/nfo/AMD_G34.cfm?pg=MOBO You know, the CPUs that started the 64-bit x86 support ... :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart: can not add MBR partitions with "gpart add -t, mbr"
On Fri, Jun 21, 2013 at 8:08 AM, Genre Roger wrote: > Hi, > > When I refer to gpart(8) manpage (9.1 release, updated jan 25,2013), I > find the description of partition types a bit confusing. > > Considering the case of a MoBo with "old way" Bios (non UEFI), the only > scheme allowed to get a bootable system is MBR. (Note that after booting, > your OS is able to manage gpt-scheme on different providers.) > You can boot off GPT partitions using the PMBR bootcode (gpart -b /boot/pmbr ada0) on just about any system. I was booting my P4 running FreeBSD 8.something off a GPT-partitioned USB stick for over a year (maybe 2?) before converting it to PC-BSD 9.1 booting off a ZFS dual-mirror pool (also using GPT partitioned disks). Can't speak to the rest of your post. I only use gpart for GPT partitioned disks, and use fdisk/bsdlabel for non-GPT partitioned disks. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: files disappearing from ls on NFS
There was just a security update that dealt with changes to getdirent or something along those lines. Check the security notices, and then see if reverting that change makes a difference. It was just in the past week here. On Thu, May 2, 2013 at 9:11 AM, Hartmut Brandt wrote: > Hi, > > I've updated one of my -current machines this week (previous update was in > february). Now I see a strange effect (it seems only on NFS mounts): ls or > even echo * will list only some files (strange enough the first files from > the normal, alphabetically ordered list). If I change something in the > directory (delete a file or create a new one) for some time the complete > listing will appear but after sime time (seconds to a minute or so) again > only part of the files is listed. > > A ktrace on ls /usr/src/lib/libc/gen shows that getdirentries is called > only once (returning 4096). For a full listing getdirentries is called 5 > times with the last returning 0. > > I can still open files that are not listed if I know their name, though. > > The NFS server is a Windows 2008 server with an OpenText NFS Server which > works without problems to all the other FreeBSD machines. > > So what could that be? > > Regards, > harti > __**_ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**current<http://lists.freebsd.org/mailman/listinfo/freebsd-current> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@** > freebsd.org " > -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Anyone have scripts for managing interfaces under new CARP setup?
On 2013-04-02 1:52 AM, "Gleb Smirnoff" wrote: > > Freddie, > > On Wed, Mar 27, 2013 at 04:10:03PM -0700, Freddie Cash wrote: > F> Just curious if anyone has any scripts for managing fail-over of multiple > F> interfaces using the new CARP setup in 10-CURRENT. > F> > F> Fail-over of all CARP vhids associated with a single interface is working > F> correctly. But, I have 2 separate, physical interfaces running with CARP, > F> and want to fail-over everything if one of the links (or boxes) goes down. > F> > F> Figured I'd ask around to see if anyone has done something like this > F> already. I've been playing with devd.conf settings and logging events, but > F> don't have anything written up to do the actual switch yet. > > Same as for old CARP, you can achieve behavior when a box with lower > advskew yields master status to a second one, setting: > > sysctl net.inet.carp.preempt=1 > > If an interface on the master has proper link state notification to the > kernel, then once the interface goes down, the advskew on the box will be > demoted and backup box will preempt it. That's how I have things set and it wasn't switching the 2nd interface. However, I think that may be due to the IPFW rules on one interface blocking CARP multicast packets on that interface, while they were going through correctly on the 2nd interface. I'll see if I can schedule a manual test later this week now that IPFW is configured correctly. Thanks for the confirmation of things are supposed to work. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Anyone have scripts for managing interfaces under new CARP setup?
Just curious if anyone has any scripts for managing fail-over of multiple interfaces using the new CARP setup in 10-CURRENT. Fail-over of all CARP vhids associated with a single interface is working correctly. But, I have 2 separate, physical interfaces running with CARP, and want to fail-over everything if one of the links (or boxes) goes down. Figured I'd ask around to see if anyone has done something like this already. I've been playing with devd.conf settings and logging events, but don't have anything written up to do the actual switch yet. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Any objections/comments on axing out old ATA stack?
On Wed, Mar 27, 2013 at 2:32 PM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > > Hi. > > > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > > stack, using only some controller drivers of old ata(4) by having > > `options ATA_CAM` enabled in all kernels by default. I have a wish to > > drop non-ATA_CAM ata(4) code, unused since that time from the head > > branch to allow further ATA code cleanup. > > > > Does any one here still uses legacy ATA stack (kernel explicitly built > > without `options ATA_CAM`) for some reason, for example as workaround > > for some regression? > > Yes, I use the legacy ATA stack. > > You're missing the reason for why you're running the old ATA stack. Do you have hardware that doesn't work with ATA_CAM? Have you not tried ATA_CAM on that box? Some other reason? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CARP will not relinquish master state on one interface
Figure it out. :( Was an IPFW rule. Seems the following two rules block CARP traffic: # Check for spoofed packets # Anti-spoof rules # These do roughly the same things: # verrevpath checks all incoming packets to see if the source IP matches any route on that interface # antispoof checks all incoming packets to make sure the source IP is not listed in a network of another interface $ipfw add 30 deny log ip from any to any not verrevpath in recv $if_public $ipfw add 40 deny log ip from any to any not antispoof in recv $if_public Removing those two rules on both boxes makes em0 fail-over correctly between the two. On Wed, Mar 27, 2013 at 2:02 PM, Freddie Cash wrote: > Two systems running identical hardware and software (one system actually > rsync'd from the other). Running 10-CURRENT just after the new CARP > implementation went in: > > FreeBSD nexus2.sd73.bc.ca 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245195: > Thu Jan 10 10:29:16 PST 2013 > r...@nexus2.sd73.bc.ca:/usr/obj/usr/src/sys/NEXUS > i386 > > Each box has 2 interfaces configured: > em0 is part of an untagged vlan > em1 is part of 8 tagged vlans > > The tagged vlan interfaces work correctly on both boxes, and CARP switches > back and forth between MASTER and BACKUP correctly, whether it be via > unplugging the network cable or via "ifconfig ... state" changes. > > The untagged vlan on both boxes will not relinquish MASTER status. If > both boxes are up, both em0 interfaces are up, then both boxes configure > the vhid as MASTER and nasty things happen to our traffic. > > The network configuration is: > > [remote site]--fibre link[fibre switch]--[carp > box1][internet] > [remote site]--fibre link--/\[carp box > 2]---/ > [remote site]--fibre link-/ > > The fibre links to the fibre switch are on untagged vlans; the link from > the switch to each carp box is a tagged vlan trunk. And the link from each > carp box to the Internet router is an untagged vlan. > > If only box1 is online, everything works correctly. > > If only box2 is online, everything works correctly. > > If both boxes are online, everything on em1 works correctly, and em0 shows > MASTER on both boxes. > > If both boxes are online but em0 is down on 1 (either) box, everything > works correctly. > > Running "tcpdump -n -i em0 -T carp | grep CARP" on both boxes shows the > CARPv2 traffic from both boxes, with the correct vhid, advbase, advskew for > each box. But the logs on box2 show "master down". > > I'm at a loss as to what to try next. Everything works for all the vlan > interfaces on em1. But nothing I've tried works for em0. Within 2 seconds > of the link showing UP, it becomes MASTER. On both boxes. > > -- > Freddie Cash > fjwc...@gmail.com > -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CARP will not relinquish master state on one interface
Two systems running identical hardware and software (one system actually rsync'd from the other). Running 10-CURRENT just after the new CARP implementation went in: FreeBSD nexus2.sd73.bc.ca 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245195: Thu Jan 10 10:29:16 PST 2013 r...@nexus2.sd73.bc.ca:/usr/obj/usr/src/sys/NEXUS i386 Each box has 2 interfaces configured: em0 is part of an untagged vlan em1 is part of 8 tagged vlans The tagged vlan interfaces work correctly on both boxes, and CARP switches back and forth between MASTER and BACKUP correctly, whether it be via unplugging the network cable or via "ifconfig ... state" changes. The untagged vlan on both boxes will not relinquish MASTER status. If both boxes are up, both em0 interfaces are up, then both boxes configure the vhid as MASTER and nasty things happen to our traffic. The network configuration is: [remote site]--fibre link[fibre switch]--[carp box1][internet] [remote site]--fibre link--/\[carp box 2]---/ [remote site]--fibre link-/ The fibre links to the fibre switch are on untagged vlans; the link from the switch to each carp box is a tagged vlan trunk. And the link from each carp box to the Internet router is an untagged vlan. If only box1 is online, everything works correctly. If only box2 is online, everything works correctly. If both boxes are online, everything on em1 works correctly, and em0 shows MASTER on both boxes. If both boxes are online but em0 is down on 1 (either) box, everything works correctly. Running "tcpdump -n -i em0 -T carp | grep CARP" on both boxes shows the CARPv2 traffic from both boxes, with the correct vhid, advbase, advskew for each box. But the logs on box2 show "master down". I'm at a loss as to what to try next. Everything works for all the vlan interfaces on em1. But nothing I've tried works for em0. Within 2 seconds of the link showing UP, it becomes MASTER. On both boxes. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NewNFS vs. oldNFS for 10.0?
Isn't the general process (or at least past pattern) to: - have 1 release cycle with just the old code (aka 8.x with oldNFS) - have 1 release cycle with old and new code, default to old (aka 9.x with oldNFS + newNFS) - have 1 release cycle with old and new code, default to new (aka 10.x with newNFS) - remove the old code from next release (aka 11.0) Or is that too long of a time-frame to migrate from old to new? On Fri, Mar 15, 2013 at 11:46 AM, Adrian Chadd wrote: > On 15 March 2013 11:11, Alfred Perlstein wrote: > > > People in my org have been working with NFS and reporting issues for the > > past year. I'm quite certain that Doug White has reported issues due to > > missing certain caching features of the old code. > > > > This is not indicative that newNFS is bad, just that it still needs some > > work. > > Good news. and yes, it needs more work, but it doesn't preclude it > from having a cutover date set. Even if that date is something far in > the future, like 11.0. > > Or we'll just end up with two NFS stacks for some undetermined amount of > time. > > > Sure, and how much NFS do you actually use and support exactly? > > .. and exactly how much would that lend to this discussion? > > I'm not arguing NFS technical details, I'm arguing project forward > thinking and planning. These don't need me to be waist deep in NFS, it > needs a broader view of how things may and may not go. > > I lived through the pain of Linux having multiple NFS implementations > for precisely this reason. It was a clusterfsck of a nightmare of epic > proportions. We should avoid that. > > > > adrian > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No ZFS when loading modules from loeader prompt
I haven't used BEs yet, as I have no ZFS-on-root systems. I just know that's how they're supposed to work, and that's the desired use case for them. Vermaden from FreeBSD Forums would be a better one to ask, as he uses them a lot and was one of the people behind BE support in FreeBSD. On 2013-02-21 4:38 PM, "Peter Jeremy" wrote: > On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann > wrote: > > At the loader prompt, I need to unload the buggy kernel and load the old > > working one via > > > > load /boot/kernel.old/kernel > > > > Then I load also the ZFS related modules > > > > load /boot/kernel.old/opensolaris.ko > > load /boot/kernel.old/zfs.ko > > > > Issuing boot at the end of that stage boots the kernel - the old one > > -successfully - but there is no working ZFS and no ZFS volume gets > > mounted although the rc.conf is executed correctly. > > > > What am I doing wrong at that point? Why isn't ZFS run and mount > properly? > > Last time I ran into this problem, the issue was that "unload" also > unloaded the zpool.cache file and the ZFS code relied on that to find > the kernel. I don't recall what the workaround was. > > On 2013-Feb-20 08:17:46 -0800, Freddie Cash wrote: > >Sounds like a perfect use case for Boot Environments. Create a new BE, > >install the new kernel into it, set it as the default, reboot. If it > >fails, you manually set the previous BE as the default, and reboot. That > >way, your "known-good", working environment is never affected. > > How do you change your BE in the loader? Or how do you change your > BE when you can't boot? > > -- > Peter Jeremy > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No ZFS when loading modules from loeader prompt
Sounds like a perfect use case for Boot Environments. Create a new BE, install the new kernel into it, set it as the default, reboot. If it fails, you manually set the previous BE as the default, and reboot. That way, your "known-good", working environment is never affected. beadm should be part of 10-CURRENT. If not, there should be a port for it. On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann wrote: > At the moment, the most recent kernel of FreeBSD 10.0-CURRENT crashes on > all of the boxes I compiled the most recent kernel sources (build a > world ncluding kernel, not only the kernel, so the system is "consistent"). > > At the loader prompt, I need to unload the buggy kernel and load the old > working one via > > load /boot/kernel.old/kernel > > Then I load also the ZFS related modules > > load /boot/kernel.old/opensolaris.ko > load /boot/kernel.old/zfs.ko > > Issuing boot at the end of that stage boots the kernel - the old one > -successfully - but there is no working ZFS and no ZFS volume gets > mounted although the rc.conf is executed correctly. > > What am I doing wrong at that point? Why isn't ZFS run and mount properly? > > Luckily, just booting the old kernel via load /boot/kernel.old/kernel > and booting it having zfs_enable="YES" in /etc/rc.conf set loads the > /boot/kernel/opensolaris/zfs stuff - usually those kernel modules are > out of sync compared to kernel.old but in this case its just a > coincidence that this works. > > So, what is the proper way to have ZFS mounted in an emergency case when > I'm in need of loading a working kernel manually? > > Regards, > Oliver > > -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ctfconvert again
The following built without any issues, including GENERIC and a custom kernel. I was pleasantly surprised that it was so easy to update from 9.0-RELEASE to 10.0-CURRENT. I was expecting a lot more manual fiddling and twiddling. [fcash@nexus2 /usr/src]$ uname -a FreeBSD nexus2.sd73.bc.ca 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245195: Thu Jan 10 10:29:16 PST 2013 r...@nexus2.sd73.bc.ca:/usr/obj/usr/src/sys/NEXUS i386 [fcash@nexus2 ~]$ cd /usr/src [fcash@nexus2 /usr/src]$ svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 245195 Node Kind: directory Schedule: normal Last Changed Author: cognet Last Changed Rev: 245192 Last Changed Date: 2013-01-08 14:55:39 -0800 (Tue, 08 Jan 2013) [fcash@nexus2 /usr/src]$ cat /etc/src.conf # Things to build that may not be built automatically WITH_IDEA=true # Build the 128-bit IDEA cipher support WITH_OPENSSH_NONE_CIPHER=true # Enable the "none" cipher in base OpenSSH # Things to not build WITHOUT_ATM=true# Don't build Asynchronous Transfer Mode support WITHOUT_BLUETOOTH=true # Don't build Bluetooth support WITHOUT_CALENDAR=true # Don't build calendar(1) WITHOUT_CTM=true# Don't build CVS-to-mail programs WITHOUT_CVS=true# Don't build cvs(1) and related tools WITHOUT_GAMES=true # Don't build the BSD games WITHOUT_HTML=true # Don't build the HTML docs WITHOUT_I4B=true# Don't build ISDB support WITHOUT_INET6=true # Don't build IPv6 support WITHOUT_INET6_SUPPORT=true # Don't build any of the other IPv6-related bits WITHOUT_IPFILTER=true # Don't build the old IPFilter packet filter WITHOUT_IPX=true# Don't build IPX protocol support WITHOUT_IPX_SUPPORT=true# Don't build any of the other IPX-related bits WITHOUT_LIBKSE=true # Don't build the old M:N threading support WITHOUT_NCP=true# Don't build Netware Control Protocol support WITHOUT_PPP=true# Don't build PPP support WITHOUT_PROFILE=true# Don't build profiled libraries WITHOUT_RCS=true# Don't build rcs(1) and related tools WITHOUT_SYSINSTALL=true # Don't build sysinstall(8) and related tools WITHOUT_WIRELESS=true # Don't build 802.11-related wireless tools WITHOUT_WIRELESS_SUPPORT=true # Don't build support tools for wireless [fcash@nexus2 /usr/src]$ cat /etc/make.conf # $FreeBSD: src/share/examples/etc/make.conf,v 1.265.2.8 2006/09/13 08:39:16 des Exp $ CPUTYPE?= opteron KERNCONF?= NEXUS GENERIC # Things to disable NO_DOCUPDATE=true NO_PORTSUPDATE=true NO_WWWUPDATE=true # Things to enable SVN_UPDATE=true # Use svn(1) to update /usr/src #BOOT_COMCONSOLE_PORT # (str) The port address to use for the console if the boot # blocks have been configured to use a serial console instead # of the keyboard/video card. # # BOOT_COMCONSOLE_SPEED # (int) The baud rate to use for the console if the boot # blocks have been configured to use a serial console instead # of the keyboard/video card. MALLOC_PRODUCTION=true # Documentation # The list of languages and encodings to build and install DOC_LANG= en_US.ISO8859-1 # Global Port Options WITHOUT_GUI=yes WITHOUT_X11=yes WITHOUT_GNOME= yes WITHOUT_IPV6= yes WITHOUT_INET6= yes # added by use.perl 2013-01-11 09:09:08 PERL_VERSION=5.16.2 -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] zfs root pool mounting
On Thu, Dec 13, 2012 at 2:49 PM, Garrett Cooper wrote: > On Thu, Dec 13, 2012 at 3:20 AM, Andriy Gapon wrote: > > ... > > > One thing that I recommend to all ZFS users is to make use of boot > environments. > > They are very easy, very convenient and may save a lot of trouble. > > Use either any of the tool available in ports (e.g. sysutils/beadm) or > just "do > > boot environments" in an ad hoc fashion: snapshot and clone your current > / known > > good boot+root filesystem and you have a safe environment to fall back > to. > > Looks interesting (this page has a slightly more in-depth description > of what beadm tries to achieve for the layman like me that doesn't use > *Solaris: > http://www.linuxquestions.org/questions/*bsd-17/howto-zfs-madness-beadm-on-freebsd-4175412036/ > ). > > You could at least point to the FreeBSD Forums version of that post. :) https://forums.freebsd.org/showthread.php?t=31662 -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: after upgrade, can't restart apache via cron
The interrupted unix faq, a wonderful thing. :) Covers this exactly. :) http://www.wonkity.com/~wblock/docs/html/interrupted.html On Nov 22, 2012 7:28 PM, "Michael W. Lucas" wrote: > > > FreeBSD bewilderbeast.blackhelicopters.org 10.0-CURRENT FreeBSD > 10.0-CURRENT #15: Thu Nov 8 14:02:45 EST 2012 > mwlu...@bewilderbeast.blackhelicopters.org:/usr/obj/usr/src/sys/GENERIC > amd64 > > I can manually restart apache22 with the following /etc/rc.conf entries: > > apache22_enable="YES" > apache22_fib=0 > > I have a cron entry that restarts apache regularly, to compensate for > some mysql daftness. > > 13 * * * * /usr/local/etc/rc.d/apache22 restart > > When this job runs, I get the following email: > > Performing sanity check on apache22 configuration: > Syntax OK > Stopping apache22. > Waiting for PIDS: 59501. > Performing sanity check on apache22 configuration: > Syntax OK > Starting apache22. > eval: setfib: not found > /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22 > > If I run /usr/local/etc/rc.d/apache22 restart from the command line, I > can restart httpd without trouble. > > Any thoughts? > > ==ml > > -- > Michael W. Lucas > http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ > Latest book: SSH Mastery > http://www.michaelwlucas.com/nonfiction/ssh-mastery > mwlu...@michaelwlucas.com, Twitter @mwlauthor > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 feels okay :-) - Hald and xorg?
On Thu, Nov 8, 2012 at 11:59 AM, Chuck Burns wrote: > Actually, KDE does -not- need hal. KDE uses the SOLID system for automatic > mounting/unmounting of removable/non-removable drives. There are two > backends for SOLID. Hal, and udisks. Since FreeBSD does not support udisks, > then the only viable SOLID backend, at the moment, is the hald one. The > kde@ team plans to eventually write a devd SOLID backend, but they are > extremely busy, so any help in that would be most welcome.. avilla@ can > probably elaborate on that.. cross-posting my reply to the kde@ ML so they > can chime in if need be. There's a devd-based automounter available in the Forums that works with KDE4: https://forums.freebsd.org/showthread.php?t=29895 -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: zpool can't bring online disk2
Sorry, can't help beyond that. I haven't played with HAST since it first hit the tree (back in 7-stable?). On Sep 23, 2012 8:10 PM, "Jose A. Lombera" wrote: > Freddie, > > ** ** > > Thanks for your great help, now makes so much sense. > > I still have a small problem, and I'm not sure if it is because hastd is > running. > > I can't initialize (hastctl create disk2) disk2 > > ** ** > > This is what I did. > > ** ** > > 1.. zpool offline tank /dev/dsk/hast/disk2 > > 2. zpool status -x > > [root@san /usr/home/jose]# zpool status -x > > pool: tank > > state: DEGRADED > > status: One or more devices has been taken offline by the administrator.** > ** > > Sufficient replicas exist for the pool to continue functioning in a > > > degraded state. > > action: Online the device using 'zpool online' or replace the device with* > *** > > 'zpool replace'. > > scan: scrub repaired 0 in 12h4m with 0 errors on Sun Sep 23 19:14:19 2012* > *** > > config: > > ** ** > > NAME STATE READ WRITE CKSUM > > tank DEGRADED 0 0 0 > > raidz1-0DEGRADED 0 0 0 > > hast/disk1ONLINE 0 0 0 > > 11919832608590631234 OFFLINE 0 0 0 was > /dev/dsk/hast/disk2 > > hast/disk3ONLINE 0 0 0 > > hast/disk4ONLINE 0 0 0 > > hast/disk5ONLINE 0 0 0 > > hast/disk6ONLINE 0 0 0 > > hast/disk7ONLINE 0 0 0 > > hast/disk8ONLINE 0 0 0 > > hast/disk9ONLINE 0 0 0 > > hast/disk10 ONLINE 0 0 0 > > ** ** > > errors: No known data errors > > ** ** > > 3. removed disk / insert a new one. > > 4. initialize > > Hastctl role init disk2 > > [root@san /usr/home/jose]# hastctl status disk2 > > disk2: > > role: init > > provname: disk2 > > localpath: /dev/mfid2 > > extentsize: 0 (0B) > > keepdirty: 0 > > remoteaddr: san1 > > replication: fullsync > > dirty: 0 (0B) > > statistics: > > reads: 0 > > writes: 0 > > deletes: 0 > > flushes: 0 > > activemap updates: 0 > > [root@san /usr/home/jose]# > > [root@san /usr/home/jose]# > > [root@san /usr/home/jose]# hastctl create disk2 > > [ERROR] [disk2] Unable to write metadata: Input/output error. > > ** ** > > ** ** > > ** ** > > I don't want to stop hastd since it will shut down the connection to my > san. > > ** ** > > Do you have any suggestion? > > ** ** > > Thanks > > ** ** > > ** ** > > --jose > > ** ** > > ** ** > > -Original Message- > From: owner-freebsd-curr...@freebsd.org [mailto: > owner-freebsd-curr...@freebsd.org] On Behalf Of Freddie Cash > Sent: Sunday, September 23, 2012 6:30 PM > To: compufutura -the computer of the future > Cc: yaneg...@gmail.com; freebsd-current@freebsd.org > Subject: RE: zpool can't bring online disk2 > > ** ** > > Since it's a HAST device, you have to initialise the disk via hastctl. > Once that is done, the /dev/hast/disk2 GEOM device node will be created.** > ** > > ** ** > > Then you can 'zpool replace' it. > > ** ** > > One step at a time. :) And you've skipped a few. > > ** ** > > 1. 'zpool offline' the defective disk > > 2. Physically remove the defective disk > > 3. Physically insert the new disk > > 4. Initialise it as a HAST resource via 'hastctl' > > 5. 'zpool replace' it using the /dev/hast node 6. Wait for the pool (and > HAST) to resilver it 7. Carry on as per normal On Sep 23, 2012 2:28 PM, > "compufutura -the computer of the future" < j...@compufutura.com> wrote:** > ** > > ** ** > > > Yanegomi, > > >** ** > > >** ** > > >** ** > > > I tried that, as you can see below, freebsd doesn’t have cfgadm > > >** ** > > > Utility to un
RE: zpool can't bring online disk2
Since it's a HAST device, you have to initialise the disk via hastctl. Once that is done, the /dev/hast/disk2 GEOM device node will be created. Then you can 'zpool replace' it. One step at a time. :) And you've skipped a few. 1. 'zpool offline' the defective disk 2. Physically remove the defective disk 3. Physically insert the new disk 4. Initialise it as a HAST resource via 'hastctl' 5. 'zpool replace' it using the /dev/hast node 6. Wait for the pool (and HAST) to resilver it 7. Carry on as per normal On Sep 23, 2012 2:28 PM, "compufutura -the computer of the future" < j...@compufutura.com> wrote: > Yanegomi, > > > > I tried that, as you can see below, freebsd doesn’t have cfgadm > > Utility to un configure the device, according to, > http://docs.oracle.com/cd/E19253-01/819-5461/gbcet/index.html, I looked > to ports but there is no utility like that. > > > > Pardon me, my knowledge is little. > > > > Can you please type the command I will need, or if I need cfgadm do I have > to look for that and install it in my freebsd box? > > > > Thanks. > > > > > > [root@san1 /usr/home/jose]# zpool offline tank hast/disk2 > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# zpool status -x > > pool: tank > > state: DEGRADED > > status: One or more devices has been taken offline by the administrator. > > Sufficient replicas exist for the pool to continue functioning in a > > degraded state. > > action: Online the device using 'zpool online' or replace the device with > > 'zpool replace'. > > scan: scrub repaired 0 in 12h4m with 0 errors on Sun Sep 23 19:14:19 2012 > > config: > > > > NAME STATE READ WRITE CKSUM > > tank DEGRADED 0 0 0 > > raidz1-0DEGRADED 0 0 0 > > hast/disk1ONLINE 0 0 0 > > 11919832608590631234 OFFLINE 0 0 0 was > /dev/hast/disk2 > > hast/disk3ONLINE 0 0 0 > > hast/disk4ONLINE 0 0 0 > > hast/disk5ONLINE 0 0 0 > > hast/disk6ONLINE 0 0 0 > > hast/disk7ONLINE 0 0 0 > > hast/disk8ONLINE 0 0 0 > > hast/disk9ONLINE 0 0 0 > > hast/disk10 ONLINE 0 0 0 > > > > errors: No known data errors > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# zpool replace tank hast/disk2 > > cannot open 'hast/disk2': no such GEOM provider > > must be a full path or shorthand device name > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# cfgadm > > bash: cfgadm: command not found > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# zpool offline tank hast/disk2 > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# > > [root@san1 /usr/home/jose]# zpool status -x > > pool: tank > > state: DEGRADED > > status: One or more devices has been taken offline by the administrator. > > Sufficient replicas exist for the pool to continue functioning in a > > degraded state. > > action: Online the device using 'zpool online' or replace the device with > > 'zpool replace'. > > scan: scrub repaired 0 in 12h4m with 0 errors on Sun Sep 23 19:14:19 2012 > > config: > > > > NAME STATE READ WRITE CKSUM > > tank DEGRADED 0 0 0 > > raidz1-0DEGRADED 0 0 0 > > hast/disk1ONLINE 0 0 0 > > 11919832608590631234 OFFLINE 0 0 0 was > /dev/hast/disk2 > > hast/disk3ONLINE 0 0 0 > > hast/disk4ONLINE 0 0 0 > > hast/disk5ONLINE 0 0 0 > > hast/disk6ONLINE 0 0 0 > > hast/disk7ONLINE 0 0 0 > > hast
Re: CARP on -CURRENT
On Fri, Feb 3, 2012 at 1:35 AM, Andrew Hobbs wrote: >> On 2 February 2012 04:26, Andrew Hobbs wrote: >> > I much appreciate the responses and I was able to get CARP functioning >> > using the new ifconfig syntax under -CURRENT. Having done that, CARP >> > is now acting as it should, though now I have a new challenge with >> > devd and automatic firing of scripts during CARP failover. It appears >> > that the documented method of doing this at >> > http://www.freebsd.org/doc/handbook/disks-hast.html no longer works >> > with the suggested devd.conf setup; notify 30 { >> > match "system" "IFNET"; >> > match "subsystem" "carp0"; >> > match "type" "LINK_UP"; >> > action "/usr/local/sbin/carp-hast-switch master"; }; >> > >> > notify 30 { >> > match "system" "IFNET"; >> > match "subsystem" "carp0"; >> > match "type" "LINK_DOWN"; >> > action "/usr/local/sbin/carp-hast-switch slave"; >> > >> > Is it likely that the triggers associated with CARP for devd have changed >> > due to the recent new CARP overhaul? Does anyone know what the new >> > triggers may be? >> > >> >> You will need to change this to something like (as taken from man carp): >> match "system" "CARP"; >> match "subsystem" "[0-9]+@"; >> match "type" "(MASTER|BACKUP)"; >> >> The subsystem now is generated as >> snprintf(subsys, IFNAMSIZ+5, "%u@%s", sc->sc_vhid, sc->sc_carpdev->if_xname); > Thanks for the info. I was able to get the triggers firing from devd. I also > noticed that the man page on 'carp' references a "carpcontrol.sh" script as > an action. Has this script been prototyped anywhere yet? Mind posting the devd.conf entries you are using? Maybe submitting a docs PR with them included, to update the HAST page? Thanks. I haven't played with HAST and the new CARP code yet. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Snapshot listing speedup.
On Jan 22, 2012 3:26 AM, "Pawel Jakub Dawidek" wrote: > > If you have many snapshots and you were complaining that listing them > takes a lot of time, you may find the commit below useful. > > It only works if your listing is limited to snapshot names and you want > to sort also by snapshot name (by default snapshots are sorted by > creation time). Would this have any effect on the speed of an 'ls' in the .zfs/snapshot/ directory? I'm guessing not, since that would have more to do with generic directory listings and general slowness in 'ls'. But one can dream. :) Afterall, the 'ls' *is* just querying the name and not all of the other ZFS properties. :D We do most of our snapshot accesses and listing via the .zfs/snapshot/ directory, which can take several seconds before the list starts to appear when there's a couple of hundred snapshots there. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On Fri, Jan 20, 2012 at 12:44 PM, Kenneth D. Merry wrote: > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS > HBAs as well as WarpDrive controllers, is available here: Just to clarify, this will replace the existing mps(4) driver in FreeBSD 10-CURRENT and 9-STABLE? So there won't be mps(4) (FreeBSD driver) and mpslsi(4) (LSI driver) anymore? Just mps(4)? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CARP on -CURRENT
On Wed, Jan 18, 2012 at 12:54 PM, Andrew Hobbs wrote: > Is CARP implemented on -CURRENT (FreeBSD 10)? Search through the mailing list archives for -current, and possibly -stable. There's a major reworking of CARP underway in -CURRENT. It's no longer a separate interface, but options assigned to an interface. There's a couple really long messages that cover it in the archives. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stable/9 still looking for packages at 9-current
On Mon, Jan 9, 2012 at 10:27 AM, Chris Rees wrote: > On 9 January 2012 18:16, Arnaud Lacombe wrote: >> ok, I'm a stupid lazy user (obviously)... While browsing the ftp, I >> see 9.0 ISOs in a `releases' directory. Do you expect me to consult >> freebsd-announce@, verify the signature of the announce, the hash of >> the ISOs, etc. to consider that 9.0 has been released ? No, I see 9.0 >> ISOs in a `releases' directory, I assume it has been released, >> whatever your spreading process is. >> >> Btw, none of the CHECKSUMS files are signed on the FTP. > > Have you checked the website? The latest supported release is clearly > specified, right in the middle of the home page. > > Please don't tell me you'd look in ftp before checking the website. I > think you're just looking to nitpick. And, which is worse: 1. tag the release branch, build the ISOs, upload to main FTP server, wait for the mirrors (FTP, CVS, SVN) to sync, then make the official announcement which includes a few days/weeks where "the release" is available but not official; or 2. tag the release branch, build the ISOs, upload to main FTP server, make the official announcement, user goes to their favourite/closest mirror, and can't access the release since it hasn't synced yet I think people would complain a hell of a lot more about 2 than they currently do about 1. Yes, people upgrading via source will see X.Y-RELEASE before it's officially announced on the website/mailing lists. Yes, people browsing ftp.freebsd.org will see X.Y-RELEASE ISOs before it's officially announced. Yes, some users will get confused by seeing X.Y-RELEASE available before the official annoucements. But, that's a lot better than making an annoucement and having users unable to use it since it's not available on their local mirrors. What's annoying, though, is that we have to go through this with every ... single ... minor ... release. It's not a hard concept, yet every time there's a new release, people get confused by it. Is there something that could be done to make it more streamlined/smoother? Maybe, maybe not. Depends. You'd have to want to join the RE team to find out more about the current release/mirror infrastructure. :) And then be willing to put in the time/effort to improve it. :D Does all of Arnaud's complaining and nit-picking constitute a request to volunteer to "fix" things? ;) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CD9660/md(4)/UFS22 silly behaviour
On Sun, Jan 8, 2012 at 2:33 PM, Kostik Belousov wrote: > On Sun, Jan 08, 2012 at 10:31:06PM +, Poul-Henning Kamp wrote: >> In message <20120108222720.gn31...@deviant.kiev.zoral.com.ua>, Kostik >> Belousov >> writes: >> >> >What is the access patern ? Is it random access, or sequential read >> >(from the cd9660 POV) ? >> >> Random access to files in the CD9660 filesystem, which stores files >> in sequential 2K blocks. > > Then it is reasonable. UFS reads full blocks. If you want/plan to use > UFS volume for small reads exclusively, you can newfs it with much > smaller block size, e.g. 8KB or even 4KB. I think the complaint is that UFS is reading 32 KB (which includes the 2 KB block and 15 others that will be needed right after) but not caching the 30 KB of data that follows the requested 2 KB. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of sysinstall from HEAD and lack of a post-install configuration tool
Not directed to Doug in particular, just selected the first message to reply to, to keep the depth of the thread from exploding. :) On Mon, Dec 26, 2011 at 3:36 PM, Doug Barton wrote: > The story so far ... > > sysinstall was removed from HEAD in October. I (and others) objected on > the basis that at this time there is no replacement for the post-install > configuration role that sysinstall played. More sysinstall components > were then removed. Then the old version of libdialog (which sysinstall > used) was removed. Thus at this point it's not possible to easily > restore sysinstall. > > So my question is, how much do you care? Is lack of that functionality > in HEAD something that we care about? Unless someone is willing to put in the time and effort to fix sysinstall such that it doesn't just spam settings to the end of the rc.conf file, it should remain dead, gone, buried, expunged, etc. While it may be nice for some users to have a pretty TUI to browse through packages, or configure networking, or whatever, sysinstall should not be it. The number of times new users have screwed up their systems by using sysinstall as a post-install configuration tool is too numerous to count. As a moderator on forums.freebsd.org, the first thing I tell new users is to forget sysinstall even exists once the OS is installed. JUST DON'T USE IT AS A POST-INSTALL CONFIGURATION TOOL! It's not worth the headaches it will cause down the line. And some of those headaches are large indeed. Plus, it doesn't support even half of the network configuration features that rc.conf support. Let alone the rest of stuff that can go into rc.conf. And it has no concept of rc.conf.local (which is very useful for configuring multiple systems that share an rc.conf). Instead of resurrecting this horrible tool, perhaps we should look at Devin Teska's host-setup tool. Or better documenting the standalone parts of sysinstall like SADE. Or even just improving the first-login fortune entry to point to a couple of useful man pages to get people started. Or even writing a new "things to do once the OS is installed" man page (similar to what OpenBSD has). sysinstall has served its purpose; and long out-lived its usefulness. It's time to let it out to pasture. Please, let's leave it in the attic where it belongs. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Wed, Dec 21, 2011 at 1:49 PM, Johan Hendriks wrote: > Nice page, but one thing i do not get is the following. > > [quote] > If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 > then the results are unlikely to tell you anything meaningful about FreeBSD > vs Ubuntu. > [/quote] > > That is a little strange in my opinion. > It tells me that FreeBSD falls more and more behind on Linux. > The reason is or could be that FreeBSD cannot or will not include GCC 4.7 > and that FreeBSD will not be on par with Linux anymore. When benchmarking two systems, you need to make sure that everything possible is the same (constants) and that the only differences between the two systems are what you want to benchmark (variables). For example, if you want to compare the performance of GCC-compiled binaries, then you would use the same hardware host, the same OS install, the same source code, and only change the compiler versions used to compile the "benchmark" binaries. That way, the only variable is "version of GCC", everything else is constant, and thus the benchmark is actually testing the performance of GCC. Likewise, if you want to benchmark the performance of two OSes, you need to eliminate as many variables as possible: - same hardware - running the same benchmark binaries - using the same versions of GCC - using the same filesystems - etc That gives you the starting point. Then, you modify one of the constants above, and re-run the benchmarks. Then you modify one more of the constants above, and re-run the benchmarks. Etc. Each time, you vary only 1 thing, so that you can measure the impact of that *ONE* thing. Comparing "random binary compile with GCC X on FreeBSD Y on filesystem Z on hardware config A" against "random binary built with GCC Q on Linux R on fileystem S on hardware config B" doesn't show anything. Was the performance difference due to hardware? Filesystem? OS? GCC version? Something else? You can't use a shotgun the thread a needle. :) > And what if in the future LLVM gets on par with Linux, is it stil fair to > compare FreeBSD with Linux? Then you add "compiler suite" to the list of variables, and you make it a constant in the first run, and then vary it one piece at a time in later runs, to isolate whether or not it affects performance. In order to do a proper comparison of any two "things", you have to first make them as equal as possible, and then vary things one bit at a time until you are at the "default" configuration for each. Only then can you really, truly, empirically say why A is better/faster/more-uber than B. Unfortunately, doing it "right" requires a lot of time, effort, time, and more time. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Thu, Dec 15, 2011 at 9:58 AM, O. Hartmann wrote: > Am 12/15/11 14:51, schrieb Daniel Kalchev: >> >> On Dec 15, 2011, at 3:25 PM, Stefan Esser wrote: >> >>> Am 15.12.2011 11:10, schrieb Michael Larabel: >>>> No, the same hardware was used for each OS. >>>> >>>> In terms of the software, the stock software stack for each OS was used. >>> >>> Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with >>> journaling enabled) should be an obvious choice since it is more similar >>> in concept to ext4 and since that is what most FreeBSD users will use >>> with FreeBSD? >> >> >> Or perhaps, since it is "server" Linux distribution, use ZFS on Linux as >> well. With identical tuning on both Linux and FreeBSD. Having the same FS >> used by both OS will help make the comparison more sensible for FS I/O. >> >> Daniel___ > > Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it > is legitimate to compare ZFS and ext4. It would be much more competetive > to compare Linux BTRFS and FreeBSD ZFS. There is a separate kernel module for ZFS that can be installed, giving you proper kernel-level support for ZFS on Linux. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Remove debug echo
So, now that you've improved the default diagnostic output of make, how about the OP's original request: make -s truly silent by removing unnecessary diagnostic messages when -s is used? :) [Thought I'd bring the thread back around to it's original purpose.] -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs i/o hangs on 9-PRERELEASE
On Fri, Nov 25, 2011 at 11:20 AM, Mark Felder wrote: > 13:14:32 nas:~ > uname -a > FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 r227971M: > Fri Nov 25 10:07:48 CST 2011 > r...@nas.feld.me:/usr/obj/**tank/svn/sys/GENERIC > amd64 > > This seemed to start happening sometime after RC1. I tried 8-STABLE and > it's happening there too right now. I think whatever caused this was MFC'd. > I've also reproduced this on completely different hardware running a single > disk ZFS pool. > > I'm getting this output in dmesg after these hangs I keep seeing. > > uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks > held: > There's a lot of uma_* stuff in there. Just curious, what's the following sysctl set to: vfs.zfs.zio.use_uma Back in the 8.x days, it was recommended to set it to 0 due to bugs: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html No idea if this is still the case or not, but you may want to try toggling that sysctl and see if it makes a difference. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Project geom-events
On Tue, Oct 4, 2011 at 12:15 PM, Garrett Cooper wrote: > On Oct 4, 2011, at 11:12 AM, Freddie Cash wrote: > > > 2011/10/4 Lev Serebryakov > > > >> One thing is missed from software RAIDs is spare drives and state > >> monitoring (yes, I know, that geom_raid supports spare drivers for > >> metadata formats which supports them, but it not universal solution). > >> > > Sounds impressive! Will be very useful for those using GEOM-based RAID > > (gmirror, gstripe, graid3, graid5, etc). > > > > Just curious: would the geom-events framework, and in particular the > > geom-events script, be useful for ZFS setups, for initiating replacements > > and providing "hot-spare" support? > > Work in the zfsd project branch already seems to do this properly. > Please note that some HBAs (like mps) don't play well with hotswap on some > branches, whereas others (mfi) might, depending on how things are coded up > and chipset support. > Cool! Sounds like we're just around the corner from having a top-notch software RAID stack via GEOM/ZFS with all the automatic goodies one expects/hopes for. :) Keep up the good work people!! -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Project geom-events
2011/10/4 Lev Serebryakov > One thing is missed from software RAIDs is spare drives and state > monitoring (yes, I know, that geom_raid supports spare drivers for > metadata formats which supports them, but it not universal solution). > Sounds impressive! Will be very useful for those using GEOM-based RAID (gmirror, gstripe, graid3, graid5, etc). Just curious: would the geom-events framework, and in particular the geom-events script, be useful for ZFS setups, for initiating replacements and providing "hot-spare" support? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun, Aug 14, 2011 at 11:35 AM, Garrett Cooper wrote: > On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash wrote: > > On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best >wrote: > > > >> hi there, > >> > >> i just had the following idea: how about instead of copying the current > >> kernel > >> to /boot/kernel.old and then installing the new one under /boot/kernel > as > >> the > >> results of target installkernel, we create a unique directory name for > the > >> old > >> kernel? > >> > >> something like /boot/kernel-r${revision}-${/dev/random}? > >> > >> that would let people not only boot the previous kernel, but all kernels > >> that > >> have been replaced by target installkernel. this would make tracking > >> issues, > >> which have been introduced by a certain commit much easier, imho. > >> > >> i don't think implementing this logic would be that difficult. the only > >> problem > >> i see is with ${/dev/random} in the case where people are running a > kernel > >> without /dev/{u}random support. > >> > > > > A better method may be to use KODIR to install the *new* kernel to a > unique > > directory via installkernel (make KERNCONF=SOMEKERNEL > > KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using > "nextboot > > -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next > boot. > > > > You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and > > then make that the default kernel (rm -rf /boot/kernel; cp -Rvp > > /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now). > > > > Sure, it's not automated yet, but the building blocks are there. > > > > This way, you never disturb the currently working kernel until you know > the > > new kernel works. And if things go south with the new kernel, a simple > > reboot is all that's needed to revert back to the working /boot/kernel. > > > > All that's needed is to automate things a bit (pick KODIR, set nextboot, > > create a post-install target of some kind to run after booting the new > > kernel). > > > > And, this leaves all of your kernels around if you want to play with > > different ones. > >Again, why build more complexity into the system when it does what > you want in a more generic manner? Just to illustrate what I do on a > weekly basis, here's my script and example invocation (I have other > instances where I have more KERNCONFs and things are more > complicated). You shouldn't have to do much more than what I did below > when dealing with your specific case of interest -- especially > because, as you and others have identified elsewhere it may not work, > it might fill up whatever partition /boot is on, etc. > Unless I'mmissing something, we're saying essentially the same thing (install new kernel to unique directory) , but you've done the work to actually automate it. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote: > hi there, > > i just had the following idea: how about instead of copying the current > kernel > to /boot/kernel.old and then installing the new one under /boot/kernel as > the > results of target installkernel, we create a unique directory name for the > old > kernel? > > something like /boot/kernel-r${revision}-${/dev/random}? > > that would let people not only boot the previous kernel, but all kernels > that > have been replaced by target installkernel. this would make tracking > issues, > which have been introduced by a certain commit much easier, imho. > > i don't think implementing this logic would be that difficult. the only > problem > i see is with ${/dev/random} in the case where people are running a kernel > without /dev/{u}random support. > A better method may be to use KODIR to install the *new* kernel to a unique directory via installkernel (make KERNCONF=SOMEKERNEL KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot. You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and then make that the default kernel (rm -rf /boot/kernel; cp -Rvp /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now). Sure, it's not automated yet, but the building blocks are there. This way, you never disturb the currently working kernel until you know the new kernel works. And if things go south with the new kernel, a simple reboot is all that's needed to revert back to the working /boot/kernel. All that's needed is to automate things a bit (pick KODIR, set nextboot, create a post-install target of some kind to run after booting the new kernel). And, this leaves all of your kernels around if you want to play with different ones. > cheers. > alex > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to install current from a memory stick and then a DVD and got a new and strange installer.
On Sun, Jul 24, 2011 at 11:51 PM, Bruce Cran wrote: > On 25/07/2011 06:01, Freddie Cash wrote: > >> Thank goodness. The worst thing about sysinstall was that it tried to be a >> Swiss Army knife doing everything, yet not doing any one thing well. It made >> a royal mess of rc.conf if you tried to use it to configure a system. >> Usually the first time someone mentions they use it for post-install >> configuration, the recommendation is to stop doing that! An os installer >> should do just that: install the os and nothing else. >> > > I tend to disagree with this. For people unfamiliar with FreeBSD using it > as a systems administration tool can be really useful, at least until they > understand where all the various configuration files are and how they work. > Having recently switched to opensuse from Ubuntu I know I find the YaST > tool incredibly useful, and probably wouldn't have continued using SuSE if > it hadn't been there. Its installer mode is one of the better installers > I've come across, and lets you fine-tune the configuration. > The difference is that YaST was designed from the get-go to be both a system management tool and a software installation tool and a system installation tool. Sysinstall was not, and sysinstall used as a post-install management tool the past couple of years has caused more issues for newbies than it's "solved". If nothing else happened to sysinstall but all the post-install crud was removed from it, it would be improved a thousand-fold. Since no one has stepped up to fix the issues with the post-install management facets of sysinstall, it's only natural to remove those bits. And, since no one wants to create a new TUI management tool, there's no reason to burden the bsdinstall devs with it. Let's make an installation tool. Later, we can worry about a TUI management tool, if it's really needed. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to install current from a memory stick and then a DVD and got a new and strange installer.
On Sunday, July 24, 2011, Ron McDowell wrote: >> > > I'll have to agree with the original poster. I have no problem with the look and feel of the new installer, but when functionality that WAS there is now gone, that's a problem. My two, make that three, biggest gripes are: > > 1) no "back" button/selection/mechanism on each screen. Rebooting because I fat-fingered something on the previous screen is, well, unacceptable. > 2) no "minimal" install. Most of my installs are single- or few-task servers where I need a base os and a couple ports. The nice thing about bsdinstall is that every install is identical. It's basically just dumping an image file to disk. > 3) I see no "post-install" uses on the new one. Sysinstall could be used on an up-and-running system to do everything from adding a user to changing a nameserver and more. Thank goodness. The worst thing about sysinstall was that it tried to be a Swiss Army knife doing everything, yet not doing any one thing well. It made a royal mess of rc.conf if you tried to use it to configure a system. Usually the first time someone mentions they use it for post-install configuration, the recommendation is to stop doing that! An os installer should do just that: install the os and nothing else. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: what is the RIGHT(TM) way to configure background DHCP?
On Wed, Jul 6, 2011 at 12:47 PM, deeptec...@gmail.com wrote: > the boot process of my FreeBSD machines takes a relatively long time. > it spends 30 seconds idling at some point, because my network > interface (sk0) is supposed to have an IP address assigned via DHCP, > and the DHCP server on my LAN takes an extremely long time (~40 > seconds) to reply to IP address requests. this is unacceptable for me; > i want the FreeBSD boot process to finish 30 seconds earlier, even if > i won't get the chance to use the network for ~40 seconds after the > booting has finished. > The simplest method would be to put into /etc/rc.conf: ifconfig_sk0="up" Then into /etc/rc.local: dhclient sk0 & That would bring your interface "up" during the boot process, then manually fire off dhclient once the normal boot process has ended (right before the login prompt appears) as a background process. By the time you login, the IP should be assigned. As for what's "the correct way" to do this via just rc.conf, I'll leave that up to others more "in the know" about how RC works. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab.
On Wed, May 4, 2011 at 8:16 AM, krad wrote: > On 4 May 2011 04:13, Jason Hellenthal wrote: >> Edwin, >> >> >>> >> /dev/acd0 /cdrom cd9660 ro,noauto 0 >> 0 >> >>> >> /dev/acd1 /cdrom1 cd9660 ro,noauto 0 >> 0 >> >> As a side note. These are also now useless & can be sent to /dev/null for >> extra padding ;) >> >> Shouldn't cause no harm being there but just for reference. >> > Just a sanity check here people, but if the machine was built with freebsd > 6.x i would guess it machine is a few years old. If so i doubt the hardware > would support ahci, and therefore wouldn't have the ada type devices, it > would have the old ad style ata ones and therefore noe fstab twiddling > should be necessary. > > Forgive me if im missing something here. If you enable "options ATA_CAM" in the kernel, which uses the old ata(4) driver via some cam(4) shims, then you also get the adaX device nodes. There's currently 4 ways to access PATA/SATA disks: - old-style ata(4) using adX device nodes - old-style ata(4) using ataahci(4) for ACHI-like access to PATA/SATA disks, I believe using adX - old-style ata(4) via ATA_CAM using adaX device nodes - new-style ahci(4)/siis(4)/another(4) using adaX device nodes I forget the name of the other AHCI-style driver. The first two options uses atacontrol to manage the disks. The last two options use camcontrol to manage the disks. I believe the plan in 9.0 is to have everything accessed via ATA_CAM/ahci(4) so all PATA/SATA drives show up the same, as adaX, with everything being managed via camcontrol, finally unifying all PATA/SATA/SCSI/SAS disk access via cam(4). -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Switch from legacy ata(4) to CAM-based ATA
On Thu, Apr 21, 2011 at 9:18 AM, Ted Faber wrote: > I seem to recall some flakiness with mounting labelled gmirrors. Anyone > know if that's been resolved? Purely anecdotal, but we've been using gmirror on top of glabel since FreeBSD 7.0. First on CompactFlash disks using CF-to-IDE adapters (ata(4)), then with CF-to-SATA adapters (ahci(4)), then with SSDs (ahci(4)). These systems have been upgraded through 7.1, 7.2, 7.3, 8.0, 8.1, 8.2, and now run 8-STABLE (from early April). No issues relating to the use of gmirror or glabel, even when replacing disks in the mirror. I've also run gmirror on glabelled USB sticks, although the quality of the sticks and the USB stack made that flaky in the extreme when combined with a very active ZFS pool (7.x days). We've since removed the CF disks and switched to using SSDs due to speed issues. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Any success stories for HAST + ZFS?
On Sun, Apr 10, 2011 at 12:36 PM, Mikolaj Golub wrote: > On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: > FC> Once the deadlock patches above are MFC'd to -STABLE, I can do an > FC> upgrade cycle and test them. > > Committed to STABLE. Updated src tree to r220537. Recompiled world, kernel, etc. Installed world, kernel, etc. ZFSv28 patch was not affected. Everything is detected correctly, everything comes up correctly. See a new option (reload) in the RC script for hast. Can create/change role for 24 hast devices simultaneously. Can switch between master/slave modes. Have 5 rsyncs running in parallel without any issues, transferring 80-120 Mbps over the network (just under 100 Mbps seems to be the average right now). Switching roles while the rsyncs are running succeeds without deadlocking (obviously, rsync complains a whole bunch while the switch happens as the pool disappears out from underneath it, but it picks up again when the pool is back in place). Hitting the reset switch on the box while the rsyncs are running doesn't affect the hast devices or the pool, beyond losing the last 5 seconds of writes. It's only been a couple of hours of testing and hammering, but so far things are much more stable/performant than before. Anything else I should test? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Any success stories for HAST + ZFS?
On Tue, Apr 5, 2011 at 5:05 AM, Mikolaj Golub wrote: > On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: > > FC> On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek > wrote: > >> > >> I just committed a fix for a problem that might look like a deadlock. > >> With trociny@ patch and my last fix (to GEOM GATE and hastd) do you > >> still have any issues? > > FC> Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? > > Yes, r220264 and 220266. As it is stated in the commit log MFC is planned > after 1 week. Okay. I'll keep an eye out next week for the MFC of those patches to hit -STABLE, and do an upgrade/test cycle after that point. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Any success stories for HAST + ZFS?
On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek wrote: > On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: >> [Not sure which list is most appropriate since it's using HAST + ZFS >> on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on >> replies.] >> >> I'm having a hell of a time making this work on real hardware, and am >> not ruling out hardware issues as yet, but wanted to get some >> reassurance that someone out there is using this combination (FreeBSD >> + HAST + ZFS) successfully, without kernel panics, without core dumps, >> without deadlocks, without issues, etc. I need to know I'm not >> chasing a dead rabbit. > > I just committed a fix for a problem that might look like a deadlock. > With trociny@ patch and my last fix (to GEOM GATE and hastd) do you > still have any issues? Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Looking through the commit logs, I don't see any of these MFC'd to -STABLE yet, so I can't test them directly. The storage box that was having the issues is running 8-STABLE r219754 at the moment (with ZFSv28 and Mikolag's ggate patches). I see there have been a lot of hast/ggate-related MFCs in the past week, but they don't include the deadlock patches. Once the deadlock patches above are MFC'd to -STABLE, I can do an upgrade cycle and test them. I do have the previous 9-CURRENT install saved, just nothing to run it on atm. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Any success stories for HAST + ZFS?
On Fri, Apr 1, 2011 at 4:22 AM, Pete French wrote: >> The other 5% of the time, the hastd crashes occurred either when >> importing the ZFS pool, or when running multiple parallel rsyncs to >> the pool. hastd was always shown as the last running process in the >> backtrace onscreen. > > This is what I am seeing - did you manage to reproduce this with the patch, > or does it fix the issue for you ? Am doing more test now, with only a single > hast device to see if it is stable. Am Ok to run without mirroring across > hast devices for now, but wouldnt like to do so long term! I have not been able to crash or hang the box since applying Mikolaj's patch. I've tried the following: - destroy pool - create pool - destroy hast providers - create hast providers - switch from master to slave via hastctl using "role secondary all" - switch from slave to master via hastctl using "role primary all" - switch roles via hast-carp-switch which does one provider per second - import/export pool I've been running 6 parallel rsyncs for the past 48 hours, getting a consistent 200 Mbps of transfers, with just under 2 TB of deduped data in the pool, without any lockups. So far, so good. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Any success stories for HAST + ZFS?
On Sun, Mar 27, 2011 at 5:16 AM, Mikolaj Golub wrote: On Sat, 26 Mar 2011 10:52:08 -0700 Freddie Cash wrote: > > FC> hastd backtrace is here: > FC> http://www.sd73.bc.ca/downloads/crash/hast-backtrace.png > > It is not a hastd crash, but a kernel crash triggered by hastd process. Ah, interesting. > I am not sure I got the same crash as you but apparently the race is possible > in g_gate on device creation. 95% of the time that it would crash, would be when creating the /dev/hast/* devices (switching to primary role). Most of the crashes happened when doing "hastctl role primary all", but would occasionally happen when doing it manually for each resource. Creating the resources by hand, one every 2 seconds or so, would usually create them all without crashing. The other 5% of the time, the hastd crashes occurred either when importing the ZFS pool, or when running multiple parallel rsyncs to the pool. hastd was always shown as the last running process in the backtrace onscreen. > I got the following crash starting many hast providers simultaneously: > > fault virtual address = 0x0 > > #8 0xc0c11adc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 > #9 0xc086ac6b in g_gate_ioctl (dev=0xc6a24300, cmd=3374345472, > addr=0xc9fec000 "\002", flags=3, td=0xc7ff0b80) > at /usr/src/sys/geom/gate/g_gate.c:410 > #10 0xc0853c5b in devfs_ioctl_f (fp=0xc9b9e310, com=3374345472, > data=0xc9fec000, cred=0xc8c9c200, td=0xc7ff0b80) > at /usr/src/sys/fs/devfs/devfs_vnops.c:678 > #11 0xc09210cd in kern_ioctl (td=0xc7ff0b80, fd=3, com=3374345472, > data=0xc9fec000 "\002") at file.h:262 > #12 0xc0921254 in ioctl (td=0xc7ff0b80, uap=0xf5edbcec) > at /usr/src/sys/kern/sys_generic.c:679 > #13 0xc0916616 in syscallenter (td=0xc7ff0b80, sa=0xf5edbce4) > at /usr/src/sys/kern/subr_trap.c:315 > #14 0xc0c2b9ff in syscall (frame=0xf5edbd28) > at /usr/src/sys/i386/i386/trap.c:1086 > #15 0xc0c11b71 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:266 > > Or just creating many ggate devices simultaneously: > > for i in `jot 100`; do > ./ggiocreate $i& > done > > ggiocreate.c is attached. > > In my case the kernel crashes in g_gate_create() when checking for name > collisions in strcmp(): > > /* Check for name collision. */ > for (unit = 0; unit < g_gate_maxunits; unit++) { > if (g_gate_units[unit] == NULL) > continue; > if (strcmp(name, g_gate_units[unit]->sc_provider->name) != 0) > continue; > mtx_unlock(&g_gate_units_lock); > mtx_destroy(&sc->sc_queue_mtx); > free(sc, M_GATE); > return (EEXIST); > } > > I think the issue is the following. When preparing sc we take > g_gate_units_lock, check for name collision, fill sc fields except > sc->sc_provider, and registers sc in g_gate_units[unit]. sc_provider is filled > later, when g_gate_units_lock is released. So the scenario is possible: > > 1) Thread A registers sc in g_gate_units[unit] with > g_gate_units[unit]->sc_provider still null and releases g_gate_units_lock. > > 2) Thread B traverses g_gate_units[] when checking for name collision and > craches accessing g_gate_units[unit]->sc_provider->name. > > The attached patch fixes the issue in my case. Patch applied cleanly to 8-STABLE with ZFSv28 patch also applied. Just to be safe, did a full buildwold/kernel cycle, running GENERIC kernel. So far, I have not been able to produce a crash in hastd, through several reboots, switching from primary to secondary and back, and just switching from primary to init and back. So far, so good. Now to see if I can reproduce any of the ZFS crashes I had earlier. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Any success stories for HAST + ZFS?
On Fri, Mar 25, 2011 at 12:55 AM, Pawel Jakub Dawidek wrote: > On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: >> I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28 >> patches, and 9-CURRENT (after the ZFSv28 commit). Things work well >> until I start hastd. Then either the system locks up, or hastd causes >> a kernel panic, or hastd dumps core. > > The minimum amount of information (as always) would be backtrace from > the kernel and also hastd backtrace when it coredumps. There is really > decent logging in hast, so I'm also sure it does log something > interesting on primary or secondary. Another useful thing would be to > turn on debugging in hast (single -d option for hastd). > > The best you can do is to give me the simplest and quickest procedure to > reproduce the issue, eg. configure two hast resources, put ZFS mirror on > top, start rsync /usr/src to the file system on top of hast and switch > roles. The simpler the better. FreeBSD 8-STABLE r219754 with the ZFSv28 patches applied. hast.conf: resource disk-a1 { local /dev/label/disk-a1 on omegadrive { remote tcp4://10.20.0.102 } on alphadrive { remote tcp4://10.20.0.101 } } resource disk-a2 { local /dev/label/disk-a2 on omegadrive { remote tcp4://10.20.0.102 } on alphadrive { remote tcp4://10.20.0.101 } } Following will crash hastd: service hastd onestart hastctl create disk-a1 hastctl create disk-a2 hastctl role primary all hastd backtrace is here: http://www.sd73.bc.ca/downloads/crash/hast-backtrace.png I'll try running it with -d to see if there's anything interesting there. Sure, running it with -d and -F, output to a log file, everything works well using 2 disks. Hrm, running it with all 24 disks, I can't make it crash now. However, I did change the kernel hz from 100 to 1000. I'll see if I can switch it back to 100 and try the tests again using -dF. The backtrace listed above is with kern.hz=100. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Any success stories for HAST + ZFS?
[Not sure which list is most appropriate since it's using HAST + ZFS on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on replies.] I'm having a hell of a time making this work on real hardware, and am not ruling out hardware issues as yet, but wanted to get some reassurance that someone out there is using this combination (FreeBSD + HAST + ZFS) successfully, without kernel panics, without core dumps, without deadlocks, without issues, etc. I need to know I'm not chasing a dead rabbit. In tests using VirtualBox and FreeBSD 8-STABLE from when HAST was first MFC'd, everything worked wonderfully. HAST-based pool would come up, data would sync to the slave node, fail-over worked nicely, bringing the other box back online as the slave worked, data synced back, etc. It was a thing of beauty. Now, on real hardware, I cannot get the system to stay online for more than an hour. :( hastd causes kernel panics with "bufwrite: buffer not busy" errors. ZFS pools get corrupted. System deadlocks (no log messages, no onscreen errors, not even NumLock key works) at random points. The hardware is fairly standard fare: - SuperMicro H8DGi-F motherboard - AMD Opteron 6100-series CPU (8-cores @ 2.0 GHz) - 8 GB DDR3 SDRAM - 64 GB Kingston V-Series SSD for the OS install (using ahci(4) and the motherboard SATA controller) - 3x SuperMicro AOC-USAS2-8Li SATA controllers with IT firmware - 6x 1.5 TB Seagate 7200.11 drives (1x raidz2 vdev) - 12x 1.0 TB Seagate 7200.12 drives (2x raidz2 vdev) - 6x 0.5 TB WD RE3 drives (1x raidz2 vdev) The motherboard BIOS is up-to-date. I do not see any way to update the firmware on the SATA controllers. Using the onboard IPMI-based sensors, CPU, motherboard, RAM temps and volatages are in the nominal range. I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28 patches, and 9-CURRENT (after the ZFSv28 commit). Things work well until I start hastd. Then either the system locks up, or hastd causes a kernel panic, or hastd dumps core. Each harddrive is glabel'd as "disk-a1" through "disk-d6". hast.conf has 24 resources listed, one for each glabel'd device. The pool is created using the /dev/hast/* devices with disk-a1 through disk-a6 being one raidz2 vdev, and so on through disk-b*, disk-c*, and disk-d*, for a total of 4 raidz2 vdevs of 6 drives each. A fairly standard setup, I would think. Even using a GENERIC kernel, I can't keep things stable and running. So, please, someone, somewhere, share a success story, where you're using FreeBSD, ZFS, and HAST. Let me know that it does work. I'm starting to lose faith in my abilities here. :( Or point out where I'm doing things wrong so I can correct the issues. Thanks. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS import panic with r219703
On Thu, Mar 17, 2011 at 10:00 AM, Olivier Smedts wrote: > 2011/3/17 Freddie Cash : >>> Hrm, it looks like the "pool roll-back on import" feature is working. >>> >>> # zpool import -F -d /dev/hast storage >>> >>> The above command imported the pool successfully. No dmu_free_range() >>> errors. No solaris assert. No kernel panic. Will try hammering on >>> the system a bit to see if that sticks or whether the space_map errors >>> show up again. >> >> Damn, of course that would be too easy. :( Adding or removing any >> data from the pool still causes it to panic with the dmu_free_range() >> assertion. > > Does resilvering help after the forced import ? I think this pool is hooped. :( It won't import in any way now, no matter what combination of options I use: readonly, force, roll-back, without the corrupted hast device so it's in a degraded state, etc. The latest panic is: solaris assert: zio-io_type != ZIO_TYPE_WRITE || spa_writable(spa), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line 2321 In case anyone is interested in the results, I've put core.txt.12 up at http://www.sd73.bc.ca/downloads/crash/ which is the core file relating to the above panic. I think after lunch I'm going to destroy the pool and start over. This box went through a lot of crashes and hangs while finding the right loader.conf tunables for hast/zfs and issues with CompactFlash for the OS. Now that I've got those set and figured out, I'm going to start over and see how things go. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS import panic with r219703
On Thu, Mar 17, 2011 at 9:24 AM, Freddie Cash wrote: > On Wed, Mar 16, 2011 at 4:03 PM, Freddie Cash wrote: >> Anytime I try to import my pool built using 24x HAST devices, I get >> the following message, and the system reboots: >> >> panic: solaris assert: dmu_free_range(os, smo->smo_object, 0, -1ULL, >> tx) == 0, file: >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/space_map.c, >> line: 484 >> >> Everything runs nicely if I don't import the pool. >> >> Doing a "zpool import" shows that one of the HAST devices is FAULTED >> "corrupted data". >> >> Haven't tried anything to remove/replace the faulted device, just >> wanted to see if anyone knew what the above error meant. >> >> Pool was created using r219523 and successfully copied over 1 TB of >> data from another ZFS system. Had some issues with gptboot this >> morning and the system locking up and rebooting a bunch, and now the >> pool won't import. > > Hrm, it looks like the "pool roll-back on import" feature is working. > > # zpool import -F -d /dev/hast storage > > The above command imported the pool successfully. No dmu_free_range() > errors. No solaris assert. No kernel panic. Will try hammering on > the system a bit to see if that sticks or whether the space_map errors > show up again. Damn, of course that would be too easy. :( Adding or removing any data from the pool still causes it to panic with the dmu_free_range() assertion. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS import panic with r219703
On Wed, Mar 16, 2011 at 4:03 PM, Freddie Cash wrote: > Anytime I try to import my pool built using 24x HAST devices, I get > the following message, and the system reboots: > > panic: solaris assert: dmu_free_range(os, smo->smo_object, 0, -1ULL, > tx) == 0, file: > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/space_map.c, > line: 484 > > Everything runs nicely if I don't import the pool. > > Doing a "zpool import" shows that one of the HAST devices is FAULTED > "corrupted data". > > Haven't tried anything to remove/replace the faulted device, just > wanted to see if anyone knew what the above error meant. > > Pool was created using r219523 and successfully copied over 1 TB of > data from another ZFS system. Had some issues with gptboot this > morning and the system locking up and rebooting a bunch, and now the > pool won't import. Hrm, it looks like the "pool roll-back on import" feature is working. # zpool import -F -d /dev/hast storage The above command imported the pool successfully. No dmu_free_range() errors. No solaris assert. No kernel panic. Will try hammering on the system a bit to see if that sticks or whether the space_map errors show up again. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS import panic with r219703
On Wed, Mar 16, 2011 at 4:03 PM, Freddie Cash wrote: > Anytime I try to import my pool built using 24x HAST devices, I get > the following message, and the system reboots: > > panic: solaris assert: dmu_free_range(os, smo->smo_object, 0, -1ULL, > tx) == 0, file: > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/space_map.c, > line: 484 > > Everything runs nicely if I don't import the pool. > > Doing a "zpool import" shows that one of the HAST devices is FAULTED > "corrupted data". > > Haven't tried anything to remove/replace the faulted device, just > wanted to see if anyone knew what the above error meant. > > Pool was created using r219523 and successfully copied over 1 TB of > data from another ZFS system. Had some issues with gptboot this > morning and the system locking up and rebooting a bunch, and now the > pool won't import. Along with this ZFS import issue, it seems that hastd doesn't like it when you fire up 24 hast devices all at once (via for loop), each with over 100 MB of dirty data in it. hast dumps core, kernel panics, and system reboots. If I do 1 hast device every 2 seconds (or however long it takes to manually type "hastctl role primary disk-a1") then it starts up fine. So, I can now panic my 9-CURRENT system by either: - starting 24 hast devices at once, or - importing a ZFS pool made up of those 24 hast devices, with 1 corrupted device Isn't testing fun? :) I have a bunch of vmcore files from the hast crashes, not really sure what to do with them, though. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"