Hi!
Not long ago, POSIX semaphores support was enabled by default as it's
becoming more widely used, by e.g. firefox. However, the support
for these is still incomplete: we only have systemwide limit of 30
semaphores, and that doesn't seem to be configurable neither online with
sysctl, nor at boot
On Sun, May 30, 2010 at 06:30:35PM +0400, Dmitry Marakasov wrote:
> Hi!
>
> Not long ago, POSIX semaphores support was enabled by default as it's
> becoming more widely used, by e.g. firefox. However, the support
> for these is still incomplete: we only have systemwide limit of 30
> semaphores, an
On 5/26/2010 11:33 PM, Alexander Motin wrote:
technews wrote:
So I've started using gmirror recently to mirror 2 1.5 TB drives however
if I reboot the machine or 'gmirror stop -f data1' while the array is
been rebuilt I get the panic below.
Rebooting without geom_mirror loaded does not cause
It is actually a security issue to automatically destroy snapshots based
on whether a filesystem is full, even automatically generated snapshots.
Since one usually implements snapshots to perform a function you wish
to rely on, such as to retain backups of historical data for auditi
On May 29, 2010, at 6:45 PM, Denny Lin wrote:
How about writing a shell script with this functionality? Get the
available disk space using:
$ zfs list -H -o avail tank
And then compare the figures against a limit. Then delete the oldest
snapshots when the limit is exceeded.
That's certainly
On May 29, 2010, at 9:58 PM, Garrett Cooper wrote:
So basically you're saying deal with an LRU snapshot deletion when you
reach a certain threshold of free space, type scheme? This might get
tricky, but it does lend itself to other systems I suppose (I hate to
mention it, but the best one I can
On May 29, 2010, at 9:42 PM, Dan Nelson wrote:
If the kernel does the snapshot deleting itself, why not add a pool-
level
property that sets the amount of free space at which the deletion
starts?
That way you don't need the cleanup script. Alternatively, make the
org.freebsd:allowautodestroy
On May 30, 2010, at 12:27 AM, Xin LI wrote:
I think this sounds like a good idea but I think we may probably want
to explore a more general mechanism, e.g. a daemon that "listen"s
system events like file system full, etc. and execute some user
defined actions.
I could definitely get on board w
On May 30, 2010, at 3:09 PM, Matthew Dillon wrote:
It is actually a security issue to automatically destroy
snapshots based
on whether a filesystem is full, even automatically generated
snapshots.
Since one usually implements snapshots to perform a function you
wish
to rely on,
Am Sonntag 30 Mai 2010 23:53:06 schrieb Kirk Strauser:
> On May 29, 2010, at 6:45 PM, Denny Lin wrote:
> > How about writing a shell script with this functionality? Get the
> > available disk space using:
> > $ zfs list -H -o avail tank
> >
> > And then compare the figures against a limit. Then de
still struggling with the attachment remover. So here is the script:
http://paste.pocoo.org/show/220207/
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
freebsd-stable@freebsd.org mail
On May 30, 2010, at 7:34 PM, Christof Schulze wrote:
still struggling with the attachment remover. So here is the script:
http://paste.pocoo.org/show/220207/
That's pretty similar in concept to the scripts I found and am using,
but with the difference that those scripts use "zfs snapshot -
On May 30, 2010, at 18:03, Kirk Strauser wrote:
The "only one need" that it addresses is that now FreeBSD would come
with a built-in recovery system. Did a "make installworld" but
screwed something up and ended up with a non-bootable system? Pop in
a recovery CD and revert to the "4 hours a
On May 29, 2010, at 16:07, Kirk Strauser wrote:
I'd propose standardizing on an attribute like
org.freebsd:allowautodestroy. Modify ZFS's disk full behavior [...]
Also run a daily periodic script to ensure that the free space stays
below a configurable threshold each day so that ZFS isn't
On Sun, May 30, 2010 at 08:33:40PM -0400, David Magda wrote:
> On May 29, 2010, at 16:07, Kirk Strauser wrote:
>
> >I'd propose standardizing on an attribute like
> >org.freebsd:allowautodestroy. Modify ZFS's disk full behavior [...]
> >Also run a daily periodic script to ensure that the free
Am Montag 31 Mai 2010 02:40:00 schrieben Sie:
> On May 30, 2010, at 7:34 PM, Christof Schulze wrote:
> > still struggling with the attachment remover. So here is the script:
> >
> > http://paste.pocoo.org/show/220207/
>
> That's pretty similar in concept to the scripts I found and am using,
> but
On May 30, 2010, at 7:40 PM, David Magda wrote:
All scriptable.
For the case of "make installworld", a make.conf variable can be
created to run a "zfs snapshot" before any kind of 'make install';
this could be for both Ports and the base system.
I understand that it comes down to a philos
On May 30, 2010, at 7:33 PM, David Magda wrote:
Why not simply have a script that runs and checks for pool usage and
then deletes snapshots with that attribute if necessary? Why do you
need to have have it built into ZFS?
That's certainly possible and I suspect most people here could knock
On 05/30/2010 18:06, Kirk Strauser wrote:
> On May 29, 2010, at 9:42 PM, Dan Nelson wrote:
>
>> If the kernel does the snapshot deleting itself, why not add a pool-level
>> property that sets the amount of free space at which the deletion starts?
>> That way you don't need the cleanup script. Alt
On May 30, 2010, at 22:17, Kirk Strauser wrote:
For instance, what happens if a disk-full condition occurs 2 minutes
before the cron job would have run that would've averted it? At what
level do you trigger deletions that would both 1) provide enough of
a safety margin that disk-fulls are u
Garrett Cooper writes:
> This is how I do it in my quickie loader.rc:
> include /boot/loader.4th
> set vfs.root.mountfrom="ufs:/dev/md0"
> load /kernel
> load -t mfs_root /mfsroot
> start
I used to do exactly this back at FreeBSD 4.11 to boot off a cdrom.
Nice to know it still works this wa
On 2010-05-30 07:42:47PM -0700, Dave Hayes wrote:
> Garrett Cooper writes:
> > This is how I do it in my quickie loader.rc:
> > include /boot/loader.4th
> > set vfs.root.mountfrom="ufs:/dev/md0"
> > load /kernel
> > load -t mfs_root /mfsroot
> > start
>
> I used to do exactly this back at Fr
On Sun, May 30, 2010 at 07:42:47PM -0700, Dave Hayes wrote:
> Garrett Cooper writes:
> > This is how I do it in my quickie loader.rc:
> > include /boot/loader.4th
> > set vfs.root.mountfrom="ufs:/dev/md0"
> > load /kernel
> > load -t mfs_root /mfsroot
> > start
>
> I used to do exactly this
Max Laier wrote:
On Friday 28 May 2010 07:46:07 Giulio Ferro wrote:
Months ago I reported a system freezing whenever bridge was used
with pf. This still happens now in 8.1 prerelease: after several minutes
to hours
that the bridge is active the system becomes unresponsive.
as I told yo
24 matches
Mail list logo
