Using a hard-disk in a Watchguard Firebox X750e for cache/log storage



  • If you install squid you probably want to turn on disk caching and also keep the logs, but using nanobsd really doesn't play well with that. I've therefore fitted a hard drive to my X750e (the details of which are covered in other posts, but which only cost me <£15) to hold the /var partition.

    Be sure to fit the "slave" link to the hard drive before you mount it in the caddy or it won't work.

    Once you've booted pfSense, get a shell, and execute the following commands.

    Format the disk thus:

    fdisk -I /dev/ad1
    bsdlabel -w ad1s1
    newfs -U /dev/ad1s1a
    

    Mount the disk and create some needed directories.

    mount /dev/ad1s1a /mnt
    cd /mnt
    /bin/mkdir -p db
    /bin/mkdir -p tmp/vi.recover/
    

    Enable writes to your CF card thus:

    /etc/rc.conf_mount_rw
    

    Then modify /etc/rc.embedded to conditionally replace the mounting of the /var ramdisk thus:

    echo -n "Setting up memory disks..."
    mdmfs -S -M -s ${tmpsize} md /tmp
    
    # If a hard disk is installed then mount that on /var
    # otherwise use a ramdisk
    harddisk="/dev/ad1s1a"
    if [ -c $harddisk ]
    then
            echo -n "Using /var physical disk..."
            mount $harddisk /var
    
            # Ensure /var/run is removed on boot before daemons are started
            # It should arguably be a tmpfs, but this works fine
            rm -r /var/run
    
            # sshd won't start if /var/empty exists on boot
            rm -r /var/empty
    else
            echo -n "Using /var memory disk..."
            mdmfs -S -M -s ${varsize} md /var
    
            # Create some needed directories
            /bin/mkdir -p /var/db
    
            # Ensure vi's recover directory is present
            /bin/mkdir -p /var/tmp/vi.recover/
    fi
    
    echo " done."
    

    Then reboot and you should see that you now have a rather large /var partition.

    df -h
    Filesystem           Size    Used   Avail Capacity  Mounted on
    /dev/ufs/pfsense1    1.8G    1.0G    641M    62%    /
    devfs                1.0k    1.0k      0B   100%    /dev
    /dev/ufs/cf           49M    1.9M     43M     4%    /cf
    /dev/md0              38M    598k     34M     2%    /tmp
    /dev/ad1s1a           36G     21M     33G     0%    /var
    devfs                1.0k    1.0k      0B   100%    /var/dhcpd/dev
    procfs               4.0k    4.0k      0B   100%    /proc
    

    You can then enable disk caching, logging etc.

    Some packages, such as sarg will still try to write to the CF card, but rather that try to find all the references to locations under /usr/local I simply created a symbolic link to a new directory on /var:

    cd /usr/local/
    ln -s /var/sarg-reports sarg-reports
    

    And then write protect the CF card thus:

    /etc/rc.conf_mount_ro
    

    Steve



  • I just installed a 2.5 in one of my x750e's and an SSD IDE in the other in order to not have to mess with CF cards anymore


  • Netgate Administrator

    Nice write-up, however I think I'm with ghostshell here. What is the advantage of doing this over running a full install booting from the hd?

    Steve



  • CF is more reliable for read-only access and a rotating-rust hard disk will last much longer than an SSD where a lot of writes are being performed. This combo therefore makes (cheap) sense for a proxy cache.

    One downside is speed… I'm only getting about 4.5Mbytes/s IO on the hard-disk which is no faster than my broadband connection.

    Has anybody tested SSD speed using diskinfo?

    The following is from a 40G 5400rpm drive, a Seagate ST9402115A:

    diskinfo -tv /dev/ad1
    /dev/ad1
    	512         	# sectorsize
    	40007761920 	# mediasize in bytes (37G)
    	78140160    	# mediasize in sectors
    	0           	# stripesize
    	0           	# stripeoffset
    	77520       	# Cylinders according to firmware.
    	16          	# Heads according to firmware.
    	63          	# Sectors according to firmware.
    	5PV09ZED    	# Disk ident.
    
    Seek times:
    	Full stroke:	  250 iter in   8.014669 sec =   32.059 msec
    	Half stroke:	  250 iter in   6.244615 sec =   24.978 msec
    	Quarter stroke:	  500 iter in   9.976294 sec =   19.953 msec
    	Short forward:	  400 iter in   3.585714 sec =    8.964 msec
    	Short backward:	  400 iter in   2.533780 sec =    6.334 msec
    	Seq outer:	 2048 iter in   0.433188 sec =    0.212 msec
    	Seq inner:	 2048 iter in   0.384784 sec =    0.188 msec
    Transfer rates:
    	outside:       102400 kbytes in  22.705212 sec =     4510 kbytes/sec
    	middle:        102400 kbytes in  22.845457 sec =     4482 kbytes/sec
    	inside:        102400 kbytes in  22.782483 sec =     4495 kbytes/sec
    

    Steve


  • Netgate Administrator

    But what happens if the disk fails? Will the box still boot? If not then you'd be better off just booting from the HD. At least then you can update the firmwhere without having to modify the scripts again.

    Steve



  • Yes, the rc.embedded change will only use the disk if the required partition is present. If not it will revert to the original ramdisk. So, this gives all the benefits of the solid state CF for long term reliability, but also provides for graceful failure. If the disk fails, just pull it from the rear of the box, then pfSense can be up and running while you wait for a new disk to arrive off eBay, plug in the new one and carry on, albeit having lost some logs and the (not very valuable) cached data which is probably stale by that point anyway.

    If fact, even if somebody tells me that an SSD is fast by comparison, I'll probably still stick with the CF for the OS, and the SSD for /var. Now that I have this working, I'm considering a 32G SSD drive as they're cheap, and spread over that size, the amount of writing my pfSense installation will do will probably see it last well.

    Steve


  • Netgate Administrator

    @Steve:

    Yes, the rc.embedded change will only use the disk if the required partition is present. If not it will revert to the original ramdisk. So, this gives all the benefits of the solid state CF for long term reliability, but also provides for graceful failure.

    Ok, you've clearly thought this through.
    Personally the ability to upgrade the firmware without having to re-edit the scripts outweighs the advantages offered by running from flash. That's just my situation though.

    Steve



  • Hi Steve,

    What scripts are you referring to?

    I run bacula on my home network, and my pfsense box has been added to that regime, so I could perform an upgrade and then restore modified scripts if desired.

    Steve


  • Netgate Administrator

    @Steve:

    What scripts are you referring to?

    /etc/rc.embedded

    If you can restore it easily enough then I guess it's less of an issue. Having more options is always good.

    Steve



  • Thanks to a post HERE by stephenw10 I've realised that my hard disk didn't have DMA enabled.

    [2.1-RELEASE][admin@pfsense]/root(18): atacontrol mode ad1
    current mode = PIO4 
    [2.1-RELEASE][admin@pfsense]/root(19): atacontrol mode ad1 UDMA6
    current mode = UDMA33 
    [2.1-RELEASE][admin@pfsense]/root(20): diskinfo -tv /dev/ad1
    /dev/ad1
    	512         	# sectorsize
    	40007761920 	# mediasize in bytes (37G)
    	78140160    	# mediasize in sectors
    	0           	# stripesize
    	0           	# stripeoffset
    	77520       	# Cylinders according to firmware.
    	16          	# Heads according to firmware.
    	63          	# Sectors according to firmware.
    	5PV09ZED    	# Disk ident.
    
    Seek times:
    	Full stroke:	  250 iter in   7.989798 sec =   31.959 msec
    	Half stroke:	  250 iter in   6.254760 sec =   25.019 msec
    	Quarter stroke:	  500 iter in   9.845523 sec =   19.691 msec
    	Short forward:	  400 iter in   3.577064 sec =    8.943 msec
    	Short backward:	  400 iter in   2.471400 sec =    6.179 msec
    	Seq outer:	 2048 iter in   0.187117 sec =    0.091 msec
    	Seq inner:	 2048 iter in   0.332214 sec =    0.162 msec
    Transfer rates:
    	outside:       102400 kbytes in   3.476458 sec =    29455 kbytes/sec
    	middle:        102400 kbytes in   3.863341 sec =    26506 kbytes/sec
    	inside:        102400 kbytes in   5.491517 sec =    18647 kbytes/sec
    

    Up to six times the speed. I'm happy with that!

    Now to figure out the neatest way to invoke that command on boot. Adding it to startup using shellcmd is the simplest way, but I daresay there's a more appropriate "freebsd" place for it.

    Steve



  • @Steve:

    Now to figure out the neatest way to invoke that command on boot. Adding it to startup using shellcmd is the simplest way, but I daresay there's a more appropriate "freebsd" place for it.

    Steve

    Setting these sysctl variables, in loader.conf.local, didn't enable DMA?

    hw.ata.wc="1"
    hw.ata.atapi_dma="1"
    hw.ata.ata_dma="1"


  • Netgate Administrator

    Doing that enables DMA globally which includes the CF card. Since the CF-IDE adapter in the firebox doesn't support DMA it will fail to boot with pages of DMA errors.

    Looks like the Shellcmd package is the way to go, no way of selectively enabling DMA per device.
    Have you tried any BIOS DMA settings?

    Steve



  • Hi Steve,

    Indeed, the issue here was that I wanted to selectively enable DMA on the hard disk only.

    No, I've not looked at the BIOS. With a current uptime of 50 days I'm loathed to reboot it to be honest. What BIOS settings are there?

    Steve


  • Netgate Administrator

    There are options for dma mode for primary master and slave separately. However those options were originally hidden and they are both set to UDMA disabled by default. Since udma still seems to be available maybe those options are not implemented. Easy test though.

    Steve



  • Now I followed the post (which is exactly what I wanted to do as well) but for whatever reason, I have two /var still mounted.  I have rebooted it a couple of times to see if I can see where it occurs or why, but have not been able to figure it out.  Any suggestions I can check as to why?  Otherwise, it works perfectly.  df -h is below:
    Filesystem          Size    Used  Avail Capacity  Mounted on
    /dev/ufs/pfsense0    442M    379M    28M    93%    /
    devfs                1.0k    1.0k      0B  100%    /dev
    /dev/ufs/cf          49M    1.4M    44M    3%    /cf
    /dev/ad1s1a          36G    10k    33G    0%    /var
    /dev/md0              38M    90k    35M    0%    /tmp
    /dev/md1              57M    17M    35M    33%    /var
    devfs                1.0k    1.0k      0B  100%    /var/dhcpd/dev

    Thanks for any help!


  • Netgate Administrator

    What does your modified rc.embedded look like?
    You should see the various messages from the modified script in the boot log, are you seeing those? Are they correct?

    Steve



  • The memory device /dev/md1 is still being created/mounted so as Stephen says you've got an issue with the startup script.

    Steve



  • No.  I see now, that it is incorrect.  I still have the original being mounted due to it.  My question is, where specifically in the original rc.embedded do I change with the Steve's changes as there are other calls in the script that I am not sure are needed or not.  Apologies, just new to the pfsense and Watchguard platforms so I am sure my questions are on the the dumber side….  The original rc.embedded is below:

    rc.embedded - embedded system specific startup information

    For pfSense

    Size of /tmp

    USE_MFS_TMP_SIZE=/usr/bin/grep use_mfs_tmp_size /cf/conf/config.xml | /usr/bin/cut -f2 -d'>' | /usr/bin/cut -f1 -d'<'

    if [ ! -z ${USE_MFS_TMP_SIZE} ] && [ ${USE_MFS_TMP_SIZE} -gt 0 ]; then
            tmpsize="${USE_MFS_TMP_SIZE}m"
    else
            tmpsize="40m"
    fi

    Size of /var

    USE_MFS_VAR_SIZE=/usr/bin/grep use_mfs_var_size /cf/conf/config.xml | /usr/bin/                                                                                 cut -f2 -d'>' | /usr/bin/cut -f1 -d'<'
    if [ ! -z ${USE_MFS_VAR_SIZE} ] && [ ${USE_MFS_VAR_SIZE} -gt 0 ]; then
            varsize="${USE_MFS_VAR_SIZE}m"
    else
            varsize="60m"
    fi

    Run some initialization routines

    [ -f /etc/rc.d/uzip ] && /etc/rc.d/uzip start

    echo -n "Setting up memory disks…"
    mdmfs -S -M -s ${tmpsize} md /tmp
    mdmfs -S -M -s ${varsize} md /var

    Create some needed directories

    /bin/mkdir -p /var/db

    Ensure vi's recover directory is present

    /bin/mkdir -p /var/tmp/vi.recover/
    echo " done."



  • Here is the complete patched /etc/rc.embedded.

    #!/bin/sh
    #
    # rc.embedded - embedded system specific startup information
    # For pfSense
    
    # Size of /tmp
    USE_MFS_TMP_SIZE=`/usr/bin/grep use_mfs_tmp_size /cf/conf/config.xml | /usr/bin/cut -f2 -d'>' | /usr/bin/cut -f1 -d'<'`
    if [ ! -z ${USE_MFS_TMP_SIZE} ] && [ ${USE_MFS_TMP_SIZE} -gt 0 ]; then
    	tmpsize="${USE_MFS_TMP_SIZE}m"
    else
    	tmpsize="40m"
    fi
    
    # Size of /var
    USE_MFS_VAR_SIZE=`/usr/bin/grep use_mfs_var_size /cf/conf/config.xml | /usr/bin/cut -f2 -d'>' | /usr/bin/cut -f1 -d'<'`
    if [ ! -z ${USE_MFS_VAR_SIZE} ] && [ ${USE_MFS_VAR_SIZE} -gt 0 ]; then
    	varsize="${USE_MFS_VAR_SIZE}m"
    else
    	varsize="60m"
    fi
    
    # Run some initialization routines
    [ -f /etc/rc.d/uzip ] && /etc/rc.d/uzip start
    
    echo -n "Setting up memory disks..."
    mdmfs -S -M -s ${tmpsize} md /tmp
    
    # If a hard disk is installed then mount that on /var
    # otherwise use a ramdisk
    harddisk="/dev/ad1s1a"
    if [ -c $harddisk ]
    then
    	echo -n "Using /var physical disk..."
    	mount -o noatime $harddisk /var
    
    	# Ensure /var/run is removed on boot before daemons are started
    	# It should arguably be a tmpfs, but this works fine
    	rm -r /var/run
    
    	# sshd won't start if /var/empty exists on boot
    	rm -r /var/empty
    else
    	echo -n "Using /var memory disk..."
    	mdmfs -S -M -s ${varsize} md /var
    
    	# Create some needed directories
    	/bin/mkdir -p /var/db
    
    	# Ensure vi's recover directory is present
    	/bin/mkdir -p /var/tmp/vi.recover/
    fi
    
    echo " done."
    


  • Thank you so much Steve!  Works perfectly.  Thanks for your patience….



  • only my result of a x5500e with a ide SSD from CWC :

    /dev/ad1s1a
            512            # sectorsize
            57872344064    # mediasize in bytes (53G)
            113031922      # mediasize in sectors
            0              # stripesize
            40448          # stripeoffset
            112134          # Cylinders according to firmware.
            16              # Heads according to firmware.
            63              # Sectors according to firmware.
            OW140822AS1514144      # Disk ident.

    Seek times:
            Full stroke:      250 iter in  0.040570 sec =    0.162 msec
            Half stroke:      250 iter in  0.037379 sec =    0.150 msec
            Quarter stroke:  500 iter in  0.125276 sec =    0.251 msec
            Short forward:    400 iter in  0.093555 sec =    0.234 msec
            Short backward:  400 iter in  0.096201 sec =    0.241 msec
            Seq outer:      2048 iter in  0.169674 sec =    0.083 msec
            Seq inner:      2048 iter in  0.123082 sec =    0.060 msec
    Transfer rates:
            outside:      102400 kbytes in  1.124830 sec =    91036 kbytes/sec
            middle:        102400 kbytes in  1.128009 sec =    90779 kbytes/sec
            inside:        102400 kbytes in  1.125042 sec =    91019 kbytes/sec

    seems that i don't have to tune anything.
    I will make the same test with a x750e soon, will let you know if somebody is interrested :)
    Regards


  • Netgate Administrator

    What tool are you testing that with? Did you enable TRIM? Be interesting to see how those figures vary over time once you've moved a few gigs across the drive.

    Steve



  • hi,

    i simply use this :

    diskinfo -tv /dev/ad1

    Trim … i did a try to enable it, but our server don't want it.
    Don't remember the problem or the error, sorry.



  • Good to see how quick this can run. If my ISP increases speed x5 I may have to get an SSD!

    Steve



  • Having updated to 2.2 the support for my hard-drive now appears rather worse.

    The atacontrol utility which did exactly what I needed has been superseded by camcontrol. This reports that the disk is in polled mode.

    $ camcontrol negotiate /dev/ada1 -v 
    Current parameters:
    (pass1:ata0:0:1:0): ATA mode: PIO4
    (pass1:ata0:0:1:0): ATAPI packet length: 0
    (pass1:ata0:0:1:0): PIO transaction length: 8192
    (pass1:ata0:0:1:0): tagged queueing: disabled
    ata0: SIM/HBA version: 1
    ata0: supports SDTR message
    ata0: scan bus sequentially
    ata0: HBA engine count: 0
    ata0: maximum target: 1
    ata0: maximum LUN: 0
    ata0: highest path ID in subsystem: 0
    ata0: initiator ID: 0
    ata0: SIM vendor: FreeBSD
    ata0: HBA vendor: ATA
    ata0: HBA vendor ID: 0x8086
    ata0: HBA device ID: 0x266f
    ata0: HBA subvendor ID: 0x8086
    ata0: HBA subdevice ID: 0x266f
    ata0: bus ID: 0
    ata0: base transfer speed: 3.300MB/sec
    ata0: maximum transfer size: 131072 bytes
    

    I should be able to set the disk to UDMA33 mode however, this is what I get.

    $ camcontrol negotiate /dev/ada1 -v -U -M UDMA33 -a
    User parameters:
    (pass1:ata0:0:1:0): ATA mode: UDMA2
    (pass1:ata0:0:1:0): ATAPI packet length: 0
    (pass1:ata0:0:1:0): PIO transaction length: 131072
    (pass1:ata0:0:1:0): tagged queueing: enabled
    ata0: SIM/HBA version: 1
    ata0: supports SDTR message
    ata0: scan bus sequentially
    ata0: HBA engine count: 0
    ata0: maximum target: 1
    ata0: maximum LUN: 0
    ata0: highest path ID in subsystem: 0
    ata0: initiator ID: 0
    ata0: SIM vendor: FreeBSD
    ata0: HBA vendor: ATA
    ata0: HBA vendor ID: 0x8086
    ata0: HBA device ID: 0x266f
    ata0: HBA subvendor ID: 0x8086
    ata0: HBA subdevice ID: 0x266f
    ata0: bus ID: 0
    ata0: base transfer speed: 3.300MB/sec
    ata0: maximum transfer size: 131072 bytes
    Unit is not ready
    (pass1:ata0:0:1:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 
    (pass1:ata0:0:1:0): CAM status: CCB request was invalid
    Test Unit Ready failed
    

    I've tried all manner of variations. Any ideas to get camcontrol to do what a simple

    atacontrol mode ad1 UDMA6
    

    would do before?

    Thanks,

    Steve


  • Netgate Administrator

    Haven't you alread set ata0 to PIO4 only though?
    The HD and CF are on the same IDE channel right?



  • Hi Stephen,

    This is what I'm trying to get my head round at the moment, reading the FreeBSD documentation to better understand the nomenclature.

    If I boot without specifying

    hint.ata.0.mode=PIO4
    

    I see the following on the console

    ada0 at ata0 bus 0 scbus0 target 0 lun 0
    ada0: <sandisk sdcfh-004g="" hdx="" 6.02=""> CFA-0 device
    ada0: Serial Number ABZ042211193008
    ada0: 66.700MB/s transfers (UDMA4, PIO 512bytes)
    ada0: 3815MB (7813120 512 byte sectors: 16H 63S/T 7751C)
    ada0: Previously was known as ad0
    ada1 at ata0 bus 0 scbus0 target 1 lun 0
    ada1: <st9402115a 3.01=""> ATA-6 device
    ada1: Serial Number 5PV09ZED
    ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
    ada1: 38154MB (78140160 512 byte sectors: 16H 63S/T 16383C)
    ada1: Previously was known as ad1</st9402115a></sandisk>
    

    Rather than

    ada0 at ata0 bus 0 scbus0 target 0 lun 0
    ada0: <sandisk sdcfh-004g="" hdx="" 6.02=""> CFA-0 device
    ada0: Serial Number ABZ042211193008
    ada0: 16.700MB/s transfers (PIO4, PIO 512bytes)
    ada0: 3815MB (7813120 512 byte sectors: 16H 63S/T 7751C)
    ada0: Previously was known as ad0
    ada1 at ata0 bus 0 scbus0 target 1 lun 0
    ada1: <st9402115a 3.01=""> ATA-6 device
    ada1: Serial Number 5PV09ZED
    ada1: 16.700MB/s transfers (PIO4, PIO 8192bytes)
    ada1: 38154MB (78140160 512 byte sectors: 16H 63S/T 16383C)
    ada1: Previously was known as ad1</st9402115a></sandisk>
    

    As you point out, this setting affects them both. I've been trying to understand what granularity of control the driver gives me. From the ata man page there's the following which suggests per device control, but I don't currently understand what "specified device" means exactly.

    @https://www.freebsd.org/cgi/man.cgi?query=ata(4)&sektion=:

    hint.ata.X.devX.mode
        limits the initial ATA mode for the specified device on the specified channel.

    hint.ata.X.mode
        limits the initial ATA mode for every device on the specified channel.

    I'm not sure how the master/slave IDE arrangement maps onto the above. Any pointers much appreciated!

    Thanks,

    Steve


  • Netgate Administrator

    Pretty sure the CF slot is always master if a CF card is in it so I would think it's dev0.

    On my test box here which I haven't set loader.conf.local on it will boot if I use:

    Hit [Enter] to boot immediately, or any other key for command prompt.
    Booting [/boot/kernel/kernel] in 4 seconds...
    
    Type '?' for a list of commands, 'help' for more detailed help.
    OK set hint.ata.0.dev0.mode=PIO4
    OK boot
    Booting...
    
    

    So I'd say you're good with that.

    Steve



  • Thank you sir, you're a scholar and a gentleman!  :)

    Your suggestion works a treat. I clearly had a bit of a mental block on what "devX" could be. I'd tried "0", but it hadn't occurred to me to used "dev0".  :-[ I'm clearly not familiar enough with FreeBSD naming conventions.

    [code]ada0 at ata0 bus 0 scbus0 target 0 lun 0
    ada0: <sandisk sdcfh-004g="" hdx="" 6.02="">CFA-0 device
    ada0: Serial Number ABZ042211193008
    ada0: 16.700MB/s transfers (PIO4, PIO 512bytes)
    ada0: 3815MB (7813120 512 byte sectors: 16H 63S/T 7751C)
    ada0: Previously was known as ad0
    ada1 at ata0 bus 0 scbus0 target 1 lun 0
    ada1: <st9402115a 3.01="">ATA-6 device
    ada1: Serial Number 5PV09ZED
    ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
    ada1: 38154MB (78140160 512 byte sectors: 16H 63S/T 16383C)
    ada1: Previously was known as ad1

    I'm now getting the performance I need for my disk used for logs and caching.

    diskinfo -tv /dev/ad1
    /dev/ad1
            512             # sectorsize
            40007761920     # mediasize in bytes (37G)
            78140160        # mediasize in sectors
            0               # stripesize
            0               # stripeoffset
            77520           # Cylinders according to firmware.
            16              # Heads according to firmware.
            63              # Sectors according to firmware.
            5PV09ZED        # Disk ident.
    
    Seek times:
            Full stroke:      250 iter in   7.926598 sec =   31.706 msec
            Half stroke:      250 iter in   6.203416 sec =   24.814 msec
            Quarter stroke:   500 iter in   9.877891 sec =   19.756 msec
            Short forward:    400 iter in   3.476113 sec =    8.690 msec
            Short backward:   400 iter in   2.381591 sec =    5.954 msec
            Seq outer:       2048 iter in   0.197696 sec =    0.097 msec
            Seq inner:       2048 iter in   0.179296 sec =    0.088 msec
    Transfer rates:
            outside:       102400 kbytes in   3.135350 sec =    32660 kbytes/sec
            middle:        102400 kbytes in   3.745807 sec =    27337 kbytes/sec
            inside:        102400 kbytes in   5.382397 sec =    19025 kbytes/sec
    
    

    Steve</st9402115a></sandisk>


  • Netgate Administrator

    Nice! I'm going to have to try that sometime.  :)

    Steve


  • Netgate Administrator

    In testing the HD issue I ran that benchmark. Thought my result might ammuse you:

    [2.2-RELEASE][root@pfSense.localdomain]/root: diskinfo -tv /dev/ada0
    /dev/ada0
            512             # sectorsize
            20003880960     # mediasize in bytes (19G)
            39070080        # mediasize in sectors
            0               # stripesize
            0               # stripeoffset
            38760           # Cylinders according to firmware.
            16              # Heads according to firmware.
            63              # Sectors according to firmware.
            32K60131T       # Disk ident.
    
    Seek times:
            Full stroke:      250 iter in  11.840086 sec =   47.360 msec
            Half stroke:      250 iter in   8.878876 sec =   35.516 msec
            Quarter stroke:   500 iter in  15.334866 sec =   30.670 msec
            Short forward:    400 iter in   8.639504 sec =   21.599 msec
            Short backward:   400 iter in   7.131472 sec =   17.829 msec
            Seq outer:       2048 iter in   0.282496 sec =    0.138 msec
            Seq inner:       2048 iter in   1.086055 sec =    0.530 msec
    Transfer rates:
            outside:       102400 kbytes in  23.521335 sec =     4353 kbytes/sec
            middle:        102400 kbytes in  20.436978 sec =     5011 kbytes/sec
            inside:        102400 kbytes in  48.862760 sec =     2096 kbytes/sec
    
    

    Something not right.  ::) Yet:

    [2.2-RELEASE][root@pfSense.localdomain]/root: dmesg | grep ada
    ada0 at ata0 bus 0 scbus0 target 0 lun 0
    ada0: <toshiba mk2018gap="" m1.42="" a="">ATA-5 device
    ada0: Serial Number 32K60131T
    ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
    ada0: 19077MB (39070080 512 byte sectors: 16H 63S/T 16383C)
    ada0: Previously was known as ad0
    Trying to mount root from ufs:/dev/ada0s1a [rw]...</toshiba> 
    

    Just a knackered old drive? Works fine though, as long as you're not in a hurry!

    Steve



  • Ouch. Not much use as a cache though as it's no faster than fiber broadband!

    Steve



  • @stephenw10:

    [2.2-RELEASE][root@pfSense.localdomain]/root: dmesg | grep ada
    ada0 at ata0 bus 0 scbus0 target 0 lun 0
    ada0: <toshiba mk2018gap="" m1.42="" a="">ATA-5 device
    ada0: Serial Number 32K60131T
    ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
    ada0: 19077MB (39070080 512 byte sectors: 16H 63S/T 16383C)
    ada0: Previously was known as ad0
    Trying to mount root from ufs:/dev/ada0s1a [rw]...</toshiba> 
    

    I was just looking in some old posts - Does it mean you have TRIM enabled on your TOSHIBA MK2018GAP drive?


  • Netgate Administrator

    No. I'm pretty sure that device is way too old to support TRIM
    TRIM only applies to SSDs anyway.

    Steve



  • That's what I knew as well but this line in your dmesg:

    ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)

    made me think otherwise.


  • Netgate Administrator

    What part of that implies TRIM?
    That's the maximum speed on the interface, which is far, far faster than the drive can manage in this case.  ;)

    Steve



  • Nothing in particular, to be honest. I see Ultra ATA/33 on my x750e as opposed to ATA/100 on yours:

    [2.2.2-RELEASE][root@wg550.home]/root: dmesg|grep ada1
    ada1 at ata0 bus 0 scbus0 target 1 lun 0
    ada1: <toshiba mk4026gax="" pa102d=""> ATA-6 device
    ada1: Serial Number 65IF3453T
    ada1: 33.300MB/s transfers (UDMA2, PIO 8192bytes)
    ada1: 38154MB (78140160 512 byte sectors: 16H 63S/T 16383C)
    ada1: Previously was known as ad1</toshiba>
    

    It says ATA-6 device, so I was hoping to see UDMA5 in the next line but UDMA2 is the ATA-4, IIRC. I'm out of sys-admin business for while now, so may be talking rubbish as well.  ;)



  • On a separate note, a really silly question (maybe): Is it worth putting a SSD in in WatchGuard/pfSense? Apart from speedy-boot, what added benefit over an PATA drive?



  • @MacUsers:

    On a separate note, a really silly question (maybe): Is it worth putting a SSD in in WatchGuard/pfSense? Apart from speedy-boot, what added benefit over an PATA drive?

    There are many IDE SSDs out to install inside and I really would go more with a SSD
    rather then a IDE HDD because of less power, faster and not so hot.


  • Netgate Administrator

    They are massively faster so if you're using it as a squid cache it will help a lot. Someone recently posted some numbers from one in the main Xe thread.

    https://forum.pfsense.org/index.php?topic=20095.msg501388#msg501388

    Steve