Re: ZFS trim patches
On 2013-07-20 07:25, aurfalien wrote: Hi, Is this; http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036777.html ... available in the form of a patch for stable rels? Its ZFS TRIM support. According to /usr/src/UPDATING, yes: 20130605: Added ZFS TRIM support which is enabled by default. To disable ZFS TRIM support set vfs.zfs.trim.enabled=0 in loader.conf. Creating new ZFS pools and adding new devices to existing pools first performs a full device level TRIM which can take a significant amount of time. The sysctl vfs.zfs.vdev.trim_on_init can be set to 0 to disable this behaviour. ZFS TRIM requires the underlying device support BIO_DELETE which is currently provided by methods such as ATA TRIM and SCSI UNMAP via CAM, which are typically supported by SSD's. Stats for ZFS TRIM can be monitored by looking at the sysctl's under kstat.zfs.misc.zio_trim. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
HOWTO monitor changes in installed packages within jails?
Hi -- I did migrate to pkgng some month ago, and ever since I am curious how to monitor changes in installed packages within jails. I am looking for a functionality/port that works like 490.status-pkg-changes for my host. Question: is there any functionality within the periodic system or a port that I might have missed to find? Thanks in advance and with kind regards, Michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: HOWTO monitor changes in installed packages within jails?
On 20/07/2013 12:09, Michael Grimm wrote:
I did migrate to pkgng some month ago, and ever since I am curious
how to monitor changes in installed packages within jails. I am
looking for a functionality/port that works like 490.status-
pkg-changes for my host.
Question: is there any functionality within the periodic system or a
port that I might have missed to find?
You can't just run 490.status-pkg-changes directly in your jail?
Try this patch:
lucid-nonsense:/tmp:% diff -u 490.status-pkg-changes{.orig,}
--- 490.status-pkg-changes.orig 2013-07-20 13:43:44.306303775 +0100
+++ 490.status-pkg-changes 2013-07-20 13:44:42.055327506 +0100
@@ -10,7 +10,7 @@
case $daily_status_pkg_changes_enable in
[Yy][Ee][Ss])
- pkgcmd=/usr/local/sbin/pkg
+ pkgcmd=/usr/local/sbin/pkg $daily_status_pkg_changes_flags
echo
echo 'Changes in installed packages:'
Then add something like the following to /etc/periodic.conf:
daily_status_pkg_changes_flags='-j jailname'
Of course, this only lets you monitor changes in one jail at a time.
You can cover more by copying the script and changing its name eg.
sed -e 's/daily_status_pkg_changes/daily_status_pkg_changes2/g' \
490.status-pkg-changes 490.status-pkg-changes2
Then add appropriate daily_status_pkg_changes2_flags='-j otherjail'
settings to periodic.conf
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk
signature.asc
Description: OpenPGP digital signature
Re: HOWTO monitor changes in installed packages within jails?
On 20.07.2013, at 14:53, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 20/07/2013 12:09, Michael Grimm wrote: I did migrate to pkgng some month ago, and ever since I am curious how to monitor changes in installed packages within jails. I am looking for a functionality/port that works like 490.status- pkg-changes for my host. Question: is there any functionality within the periodic system or a port that I might have missed to find? You can't just run 490.status-pkg-changes directly in your jail? Yes, I can ;-) But! I do have a lot of service jails running at my host, thus I would like to omit modifying every jail's /etc/periodic.conf adding: | daily_status_pkg_changes_enable=YES# Show package changes | pkg_info=pkg info # Use this program Try this patch: Thanks for that approach, namely adding pkg -j jailname info for every jail running. Due to my amount of jails I might need to add some looping over jls -N output instead of adding a lot of $daily_status_pkg_changes_flags. I was hoping that I could omit programming that functionality myself, but I might need to do so. Thanks for your input and with kind regards, Michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: to gmirror or to ZFS
On 16/07/2013 20:48, Charles Swiger wrote: Hi-- On Jul 16, 2013, at 11:27 AM, Johan Hendriks joh.hendr...@gmail.com wrote: Well, don't do that. :-) When the server reboots because of a powerfailure at night, then it boots. Then it starts to rebuild the mirror on its own, and later the fsck kicks in. Not much i can do about it. Maybe i should have done it without the automatic attachment for a new device. It's normally the case that getting a hot spare automatically attached should be fine, but not if you also have the box go down entirely and need to fsck. I'm more used to needing to explicitly physically swap out a failed mirror component, in which case one can make sure the system is OK before the replacement drive goes in. Agreed. Blaming gmirror for this kind of thing overlooks the overall design and operating procedures of the system, and assuming ZFS would have been any better may be wishful thinking. I've had plenty of gmirror crashes over the years, and they have all been recoverable. One thing I never allow it to do is to rebuild automatically. That's something for a human to initiate once the problem has been identified, and if it's flaky power in the data centre the job is postponed until I'm satisfied it's not going to drop during the rebuild. IME, one power failure is normally followed by several more. It's worth noting, as a warning for anyone who hasn't been there, that the number of times a second drive in a RAID system fails during a rebuild is higher than would be expected. During a rebuild the remaining drives get thrashed, hot, and if they're on the edge, that's when they're going to go. And at the most inconvenient time. Okay - obvious when you think about it, but this tends to be too late. Regards, Frank. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: to gmirror or to ZFS
On Sat, 20 Jul 2013 18:14:20 +0100 Frank Leonhardt fra...@fjl.co.uk wrote: It's worth noting, as a warning for anyone who hasn't been there, that the number of times a second drive in a RAID system fails during a rebuild is higher than would be expected. During a rebuild the remaining drives get thrashed, hot, and if they're on the edge, that's when they're going to go. And at the most inconvenient time. Okay - obvious when you think about it, but this tends to be too late. Having the cabinet stuffed full of nominally identical drives bought at the same time from the same supplier tends to add to the probability that more than one drive is on the edge when one goes. It's a pity there are now only two manufacturers of spinning rust. -- Steve O'Hara-Smith st...@sohara.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
themerchantsolutions.com: You are now unsubscribed
** We have removed your email address from our list. We're sorry to see you go. Was this a mistake? Did you forward one of our emails to a friend, and they clicked the unsubscribe link not realizing they were in fact unsubscribing you from this list? If this was a mistake, you can re-subscribe at: Subscribe (http://blogspot.us6.list-manage1.com/subscribe?u=37964f600b3d95d5cb34024a4id=1bd9b49122) For questions or comments, please contact us at: cutt...@gmail.com (mailto:cutt...@gmail.com) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Convert flat PDF to interactive PDF
I am looking for an application that can convert a standard flat PDF file into an interactive PDF. I can locate several that work under MS Windows, including Acrobat XI; however, I was trying to find one that will work under KDE on FreeBSD. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: to gmirror or to ZFS
On Sat, 20 Jul 2013, Steve O'Hara-Smith wrote: On Sat, 20 Jul 2013 18:14:20 +0100 Frank Leonhardt fra...@fjl.co.uk wrote: It's worth noting, as a warning for anyone who hasn't been there, that the number of times a second drive in a RAID system fails during a rebuild is higher than would be expected. During a rebuild the remaining drives get thrashed, hot, and if they're on the edge, that's when they're going to go. And at the most inconvenient time. Okay - obvious when you think about it, but this tends to be too late. Having the cabinet stuffed full of nominally identical drives bought at the same time from the same supplier tends to add to the probability that more than one drive is on the edge when one goes. It's a pity there are now only two manufacturers of spinning rust. Often this is presummed to be the reason for double failures close in time, also common mode failures such as environment, a defective power supply or excess voltage can be blamed. I have to think that the most common cause for a second failure soon after the first is that a failed drive often isn't detected until a particular sector is read or written. Since the resilvering reads and writes every sector on multiple disks, including unused sectors, it can detect latent problems that may have existed since the drive was new but which haven't been used for data yet, or have gone bad since the last write, but haven't been read since. The ZFS scrub processes only sectors with data, so it provides only partial protection against double failures. Daniel Feenberg NBER -- Steve O'Hara-Smith st...@sohara.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: to gmirror or to ZFS
On 21/07/2013 04:42, Steve O'Hara-Smith wrote: It's a pity there are now only two manufacturers of spinning rust. I thought there was three left - Seagate WD and Toshiba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[SOLVED] Prevent starting network on fwe0 and fwip0
On Saturday 18 May 2013 16:57:31 Martin Alejandro Paredes Sanchez wrote:
Hi:
How can I prevent the start of network on fwe0 and fwip0?
fwe0: Ethernet over FireWire
fwip0: IP over FireWire
I notice that the lines apear after DEVD is started
Is there a trick for DEVD?
I created the /usr/local/etc/devd/firewire.conf file with
notify 0 {
match system IFNET;
match subsystem (fwe0|fwip0);
};
With this, FreeBSD do not start the network on fwe0 and fwip0
You won't see
Starting Network: fwe0
Starting Network: fwip0
But this drivers are loaded (fwe0 and fwip0), with ifconfig you can see the
configuration of them
HTH
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
