Carson Gaspar wrote:
On 10/26/09 5:33 PM, p...@paularcher.org wrote:
I can't find much on gam_server on Solaris (couldn't find too much
on it
at all, really), and port_create is apparently a system call. (I'm
not a
developer--if I can't write it in BASH, Perl, or Ruby, I can't write
it.)
I
On Nov 10, 2009, at 10:23 AM, Andrew Daugherity wrote:
For example:
rsync -avn --delete-before /export/ims/.zfs/snapshot/zfs-auto-
snap_daily-2009-11-09-1900/ /export/ims/.zfs/snapshot/zfs-auto-
snap_daily-2009-11-08-1900/
[...]
If you cared to see changes within files (I don't),
toss
Thanks for info, although the audit system seems a lot more complex than what I
need. Would still be nice if they fixed bart to work on large filesystems,
though.
Turns out the solution was right under my nose -- rsync in dry-run mode works
quite well as a snapshot diff tool. I'll share this
I'd hoped this script would work for me as a snapshot diff script, but it
seems that bart doesn't play well with large filesystems (don't know the
cutoff, but my zfs pools (other than rpool) are all well over 4TB).
'bart create' fails immediately with a Value too large for defined data type
Andrew Daugherity wrote:
if I invoke bart via truss, I see it calls statvfs() and fails. Way to keep up
with the times, Sun!
% file /bin/truss /bin/amd64/truss
/bin/truss: ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information
On Mon, Nov 09, 2009 at 03:25:02PM -0700, Robert Thurlow wrote:
Andrew Daugherity wrote:
if I invoke bart via truss, I see it calls statvfs() and fails. Way to
keep up with the times, Sun!
% file /bin/truss /bin/amd64/truss
/bin/truss: ELF 32-bit LSB executable 80386 Version 1
On Nov 9, 2009, at 2:06 PM, Andrew Daugherity wrote:
I'd hoped this script would work for me as a snapshot diff script,
but it seems that bart doesn't play well with large filesystems
(don't know the cutoff, but my zfs pools (other than rpool) are all
well over 4TB).
'bart create' fails
Robert Thurlow robert.thur...@sun.com 11/9/2009 4:25 PM
% file /bin/truss /bin/amd64/truss
/bin/truss: ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available
/bin/amd64/truss: ELF 64-bit LSB executable AMD64 Version 1
Seems to me that you really want auditing. You can configure the audit
system to only record the events you are interested in.
http://docs.sun.com/app/docs/doc/816-4557/auditov-1?l=ena=view
-- richard
On Nov 9, 2009, at 4:55 PM, Andrew Daugherity wrote:
Robert Thurlow
Paul
Being a script hacker like you the only kludge I can think of.
A script that does something like
ls /tmp/foo
sleep
ls /tmp/foo.new
diff /tmp/foo /tmp/foo.new
/tmp/files_that_have_changed
mv /tmp/foo.new /tmp/foo
Or you might be able to knock something up with bart nd zfs snapshots.
On 10/25/09 5:38 PM, Paul Archer wrote:
5:12pm, Cyril Plisko wrote:
while there is no inotify for Solaris, there are similar technologies
available.
Check port_create(3C) and gam_server(1)
I can't find much on gam_server on Solaris (couldn't find too much on it
at all, really), and
How about a consumer for gvfs-monitor-dir(1) or gvfs-monitor-
file(1)? :-)
-- richard
On Oct 26, 2009, at 3:17 PM, Carson Gaspar wrote:
On 10/25/09 5:38 PM, Paul Archer wrote:
5:12pm, Cyril Plisko wrote:
while there is no inotify for Solaris, there are similar
technologies
available.
On 10/26/09 3:31 PM, Richard Elling wrote:
How about a consumer for gvfs-monitor-dir(1) or gvfs-monitor-file(1)? :-)
The docs are... ummm... skimpy is being rather polite. The docs I can find via
Google say that they will launch some random unspecified daemons via d-bus (I
assume gvfsd ans
On Oct 26, 2009, at 3:56 PM, Carson Gaspar wrote:
On 10/26/09 3:31 PM, Richard Elling wrote:
How about a consumer for gvfs-monitor-dir(1) or gvfs-monitor-
file(1)? :-)
The docs are... ummm... skimpy is being rather polite. The docs I
can find via Google say that they will launch some
I can't find much on gam_server on Solaris (couldn't find too much on it
at all, really), and port_create is apparently a system call. (I'm not a
developer--if I can't write it in BASH, Perl, or Ruby, I can't write
it.)
I appreciate the suggestions, but I need something a little more
On 10/26/09 5:33 PM, p...@paularcher.org wrote:
I can't find much on gam_server on Solaris (couldn't find too much on it
at all, really), and port_create is apparently a system call. (I'm not a
developer--if I can't write it in BASH, Perl, or Ruby, I can't write
it.)
I appreciate the
On Oct 26, 2009, at 20:42, Carson Gaspar wrote:
Unfortunately, I'm trying for a Solaris solution. I already had a
Linux
solution (the 'inotify' I started out with).
And we're on a Solaris mailing list, trying to give you solutions
that work on Solaris. Don't believe everything you read on
I haven't tried this, but this must be very easy with dtrace. How come no one
mentioned it yet? :) You would have to monitor some specific syscalls...
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
On Mon, Oct 26, 2009 at 08:53:50PM -0700, Anil wrote:
I haven't tried this, but this must be very easy with dtrace. How come
no one mentioned it yet? :) You would have to monitor some specific
syscalls...
DTrace is not reliable in this sense: it will drop events rather than
overburden the
OK, so this may be a little off-topic, but here goes:
The reason I switched to OpenSolaris was primarily to take advantage of ZFS's
features when storing my digital imaging collection.
I switched from a pretty stock Linux setup, but it left me at one
disadvantage. I had been using inotify
On Sun, Oct 25, 2009 at 4:16 PM, Paul Archer p...@paularcher.org wrote:
OK, so this may be a little off-topic, but here goes:
The reason I switched to OpenSolaris was primarily to take advantage of
ZFS's features when storing my digital imaging collection.
I switched from a pretty stock Linux
5:12pm, Cyril Plisko wrote:
Question: Is there a facility similar to inotify that I can use to monitor a
directory structure in OpenSolaris/ZFS, such that it will block until a file
is modified (added, deleted, etc), and then pass the state along (STDOUT is
fine)? One other requirement: inotify
22 matches
Mail list logo
