Re: [Haifux] content directory mirroring
I also used the no-whole option;
rsync --progress --stats --compress --recursive --rsh=ssh \
--partial --no-whole-file \
[EMAIL PROTECTED]:~mpower/content/cdr ~mpower/content/cdr
but it still copy everything.
-Original Message-
From: Biran, Yahav (Yahav) [mailto:[EMAIL PROTECTED]
Sent: Monday, May 12, 2008 11:14 PM
To: 'haifux@haifux.org'
Subject: content directory mirroring
I'm implementing a geo- redundancy solution for a web application.
The main task is to synchronize the content directory from the active site
to the stand-by site.
I tried to do it with rsync utility by setting rsync server that initiate an
rsync transfer.
My problem is that it keeps copy all the directories and sub directories
from scratch.
I wish to copy only the delta from last execution.
Im executing the following:
rsync --progress --stats --compress --recursive --rsh=ssh --partial \
dest_path [EMAIL PROTECTED]:src_path
I was trying to calculate the delta files by executing in the source host:
rsync -avR [EMAIL PROTECTED]:'`find src_path -atime -${T2-T1}`'
where T2 and T1 are the delta time duration.
But its not seem to be the right way.
Is anybody knows more elegant way to mirror two sites by transferring only
delta information?
Yahav Biran
Alcatel-Lucent
Multimedia Content Platforms
5 Nahum Het Street, 3rd floor
Topaz Building, Shaar Hacarmel
POB 15049
Haifa 31905, Israel
Email: [EMAIL PROTECTED]
Cell: +972 54 6616208
Phone: +972 4 8138020
Fax: +972 4 8138022
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
[Haifux] content directory mirroring
I'm implementing a geo- redundancy solution for a web application.
The main task is to synchronize the content directory from the active site
to the stand-by site.
I tried to do it with rsync utility by setting rsync server that initiate an
rsync transfer.
My problem is that it keeps copy all the directories and sub directories
from scratch.
I wish to copy only the delta from last execution.
Im executing the following:
rsync --progress --stats --compress --recursive --rsh=ssh --partial \
dest_path [EMAIL PROTECTED]:src_path
I was trying to calculate the delta files by executing in the source host:
rsync -avR [EMAIL PROTECTED]:'`find src_path -atime -${T2-T1}`'
where T2 and T1 are the delta time duration.
But its not seem to be the right way.
Is anybody knows more elegant way to mirror two sites by transferring only
delta information?
Yahav Biran
Alcatel-Lucent
Multimedia Content Platforms
5 Nahum Het Street, 3rd floor
Topaz Building, Shaar Hacarmel
POB 15049
Haifa 31905, Israel
Email: [EMAIL PROTECTED]
Cell: +972 54 6616208
Phone: +972 4 8138020
Fax: +972 4 8138022
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Suggested lecture: "Crash and burn: writing Linux application fault handlers"
I am interested.
Gabi
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Gilad Ben-Yossef
Sent: Monday, May 12, 2008 10:48 AM
To: haifux@haifux.org
Subject: [Haifux] Suggested lecture: "Crash and burn: writing Linux
application fault handlers"
Howdy folks,
I'd like to suggest a lecture for Haifux meeting.
Title: Crash and burn: writing Linux application fault handlers
Abstract:
Complementing the standard Linux fault handler ("Segmentation fault.
Core dumped.") with a custom handler that reports the crashing program state
without a debugger is a useful endeavor in many situations.
Unfortunately, writing such a fault handler correctly can be surprisingly
hard and requires certain amount of black magic.
The proposed lecture is a tutorial that will demonstrate how to write such a
handler, covering such topics as: getting program symbolic stack trace and
registers and reporting them safely, the care and feeding of async signal
POSIX handler functions, how to avoid implicit memory allocations and how to
test for them, how to handle multi-threaded faults, the black magic involved
with how Linux handles signal handlers, the unfortunate effect this has on
obtaining a correct stack trace in case of a fault and how to overcome this
limitation.
Let me know if there is interest and available times.
Cheers,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
Codefidence Ltd.
The code is free, your time isn't.(TM)
Web: http://codefidence.com
Email: [EMAIL PROTECTED]
Office: +972-8-9316883 ext. 201
Fax: +972-8-9316885
Mobile: +972-52-8260388
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Suggested lecture: "Crash and burn: writing Linux application fault handlers"
Sure, schedule it.
>
> Howdy folks,
>
> I'd like to suggest a lecture for Haifux meeting.
>
> Title: Crash and burn: writing Linux application fault handlers
>
> Abstract:
>
> Complementing the standard Linux fault handler ("Segmentation fault.
> Core dumped.") with a custom handler that reports the crashing program
> state without a debugger is a useful endeavor in many situations.
> Unfortunately, writing such a fault handler correctly can be
> surprisingly hard and requires certain amount of black magic.
>
> The proposed lecture is a tutorial that will demonstrate how to write
> such a handler, covering such topics as: getting program symbolic stack
> trace and registers and reporting them safely, the care and feeding of
> async signal POSIX handler functions, how to avoid implicit memory
> allocations and how to test for them, how to handle multi-threaded
> faults, the black magic involved with how Linux handles signal handlers,
> the unfortunate effect this has on obtaining a correct stack trace in
> case of a fault and how to overcome this limitation.
>
> Let me know if there is interest and available times.
>
> Cheers,
> Gilad
>
> --
> Gilad Ben-Yossef
> Chief Coffee Drinker
>
> Codefidence Ltd.
> The code is free, your time isn't.(TM)
>
> Web: http://codefidence.com
> Email: [EMAIL PROTECTED]
> Office: +972-8-9316883 ext. 201
> Fax: +972-8-9316885
> Mobile: +972-52-8260388
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
>
--
"Change is inevitable; progress is optional".
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Suggested lecture: "Crash and burn: writing Linux application fault handlers"
This goes under "why bother asking, just schedule it!" Eli Gilad Ben-Yossef wrote: > Howdy folks, > > I'd like to suggest a lecture for Haifux meeting. > > Title: Crash and burn: writing Linux application fault handlers > > > ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Suggested lecture: "Crash and burn: writing Linux application fault handlers"
On Mon, May 12, 2008 at 10:48 AM, Gilad Ben-Yossef
<[EMAIL PROTECTED]> wrote:
>
> Howdy folks,
>
> I'd like to suggest a lecture for Haifux meeting.
>
> Title: Crash and burn: writing Linux application fault handlers
>
> Abstract:
>
> Complementing the standard Linux fault handler ("Segmentation fault.
> Core dumped.") with a custom handler that reports the crashing program
> state without a debugger is a useful endeavor in many situations.
> Unfortunately, writing such a fault handler correctly can be
> surprisingly hard and requires certain amount of black magic.
>
> The proposed lecture is a tutorial that will demonstrate how to write
> such a handler, covering such topics as: getting program symbolic stack
> trace and registers and reporting them safely, the care and feeding of
> async signal POSIX handler functions, how to avoid implicit memory
> allocations and how to test for them, how to handle multi-threaded
> faults, the black magic involved with how Linux handles signal handlers,
> the unfortunate effect this has on obtaining a correct stack trace in
> case of a fault and how to overcome this limitation.
>
> Let me know if there is interest and available times.
I'm voting for "yes!!" with both hands!
>
> Cheers,
> Gilad
>
> --
> Gilad Ben-Yossef
> Chief Coffee Drinker
>
> Codefidence Ltd.
> The code is free, your time isn't.(TM)
>
> Web: http://codefidence.com
> Email: [EMAIL PROTECTED]
> Office: +972-8-9316883 ext. 201
> Fax: +972-8-9316885
> Mobile: +972-52-8260388
> ___
> Haifux mailing list
> Haifux@haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
--
Zaar
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
[Haifux] Suggested lecture: "Crash and burn: writing Linux application fault handlers"
Howdy folks,
I'd like to suggest a lecture for Haifux meeting.
Title: Crash and burn: writing Linux application fault handlers
Abstract:
Complementing the standard Linux fault handler ("Segmentation fault.
Core dumped.") with a custom handler that reports the crashing program
state without a debugger is a useful endeavor in many situations.
Unfortunately, writing such a fault handler correctly can be
surprisingly hard and requires certain amount of black magic.
The proposed lecture is a tutorial that will demonstrate how to write
such a handler, covering such topics as: getting program symbolic stack
trace and registers and reporting them safely, the care and feeding of
async signal POSIX handler functions, how to avoid implicit memory
allocations and how to test for them, how to handle multi-threaded
faults, the black magic involved with how Linux handles signal handlers,
the unfortunate effect this has on obtaining a correct stack trace in
case of a fault and how to overcome this limitation.
Let me know if there is interest and available times.
Cheers,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
Codefidence Ltd.
The code is free, your time isn't.(TM)
Web: http://codefidence.com
Email: [EMAIL PROTECTED]
Office: +972-8-9316883 ext. 201
Fax: +972-8-9316885
Mobile: +972-52-8260388
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
