Quantcast

NBAK simplification RFC

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

NBAK simplification RFC

Nikolay Samofatov
Hello, All!

It appears I now have some time to look into old issues.

I know for a long time that it is possible to optimize NBAK module:
Currently, difference file page is allocated inside CCH_mark and this is
sub-optimal.

This has not been the case during nbackup development. Early version
allocated difference pages much later, just before writing a page - in
write_page function.

This didn't work because lock manager calls could not be used inside AST
handlers due to signals handling logic.

Another issue at play here is early "disk full" failure path during
CCH_mark rather then write_page, but I am not sure it really matters in
terms of possible database corruption - "careful write" should in theory
take care of things even if write_page fails due to "disk full"
condition.

Firebird doesn't use signals for AST delivery for a long time already
and it might be possible to issue new locks from inside AST handler.

Therefore it might make sense to go back to this logic. This would make
nbackup state locks very transient and do not require flushing page
cache during transitions.

It also might be possible to use shared memory for synchronization
instead of lock manager calls to speed things up.

I might do either or both of those things.

What do you think? Is it worthwhile to spend time and effort in this
area? Or better consider NBAK stable and fast enough and address some
other issue?

Nikolay Samofatov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[SPAM] Re: NBAK simplification RFC

Vlad Khorsun-2
20.03.2017 17:49, Nikolay Samofatov wrote:

> Hello, All!
>
> It appears I now have some time to look into old issues.
>
> I know for a long time that it is possible to optimize NBAK module:
> Currently, difference file page is allocated inside CCH_mark and this is
> sub-optimal.
>
> This has not been the case during nbackup development. Early version
> allocated difference pages much later, just before writing a page - in
> write_page function.
>
> This didn't work because lock manager calls could not be used inside AST
> handlers due to signals handling logic.
>
> Another issue at play here is early "disk full" failure path during
> CCH_mark rather then write_page, but I am not sure it really matters in
> terms of possible database corruption - "careful write" should in theory
> take care of things even if write_page fails due to "disk full"
> condition.

   Practice shows that careful write can't help there. And i failed to see how
CW could help in case of out of disk condition for delta file, which contains
pages not in database order.

> Firebird doesn't use signals for AST delivery for a long time already
> and it might be possible to issue new locks from inside AST handler.
>
> Therefore it might make sense to go back to this logic. This would make
> nbackup state locks very transient and do not require flushing page
> cache during transitions.

   It would be very good to avoid flushing.

> It also might be possible to use shared memory for synchronization
> instead of lock manager calls to speed things up.

   Could you explain more ?

> I might do either or both of those things.
>
> What do you think? Is it worthwhile to spend time and effort in this
> area? Or better consider NBAK stable and fast enough and address some
> other issue?

   Hard to say. Probably it depends on what another issue you want to address ;)

Regards,
Vlad


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NBAK simplification RFC

Dmitry Yemanov-3
20.03.2017 19:43, Vlad Khorsun wrote:
>
>> Firebird doesn't use signals for AST delivery for a long time already
>> and it might be possible to issue new locks from inside AST handler.
>>
>> Therefore it might make sense to go back to this logic. This would make
>> nbackup state locks very transient and do not require flushing page
>> cache during transitions.
>
>    It would be very good to avoid flushing.

Agreed. But I'm really worried about taking locks in ASTs, this sounds
as a dangerous practice to me. I smell new deadlocks.

>> It also might be possible to use shared memory for synchronization
>> instead of lock manager calls to speed things up.
>
>    Could you explain more ?

I suppose Nickolay means replacing GlobalRWLock with native OS-level RW
primitives used similar to shared memory mutexes. For Windows, they're
just shared as named objects, for POSIX they're stored in shmem.


Dmitry


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NBAK simplification RFC

Dmitry Yemanov-3
20.03.2017 20:06, Dmitry Yemanov wrote:
>
> Agreed. But I'm really worried about taking locks in ASTs, this sounds
> as a dangerous practice to me. I smell new deadlocks.

Just to clarify: I meant taking LM locks here. It could be safer for
low-level locks.


Dmitry


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NBAK simplification RFC

Dimitry Sibiryakov-3
In reply to this post by Dmitry Yemanov-3
20.03.2017 18:06, Dmitry Yemanov wrote:
> I suppose Nickolay means replacing GlobalRWLock with native OS-level RW
> primitives used similar to shared memory mutexes. For Windows, they're
> just shared as named objects, for POSIX they're stored in shmem.

   On Windows they also could be Critical Sections stored in shared memory...


--
   WBR, SD.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NBAK simplification RFC

Alex Peshkoff
In reply to this post by Dmitry Yemanov-3
On 03/20/17 20:06, Dmitry Yemanov wrote:

> 20.03.2017 19:43, Vlad Khorsun wrote:
>>> Firebird doesn't use signals for AST delivery for a long time already
>>> and it might be possible to issue new locks from inside AST handler.
>>>
>>> Therefore it might make sense to go back to this logic. This would make
>>> nbackup state locks very transient and do not require flushing page
>>> cache during transitions.
>>     It would be very good to avoid flushing.
> Agreed. But I'm really worried about taking locks in ASTs, this sounds
> as a dangerous practice to me. I smell new deadlocks.

Yes, that did not work in crypto manager. Had to use regular re-reading
of lock's data. Not fast but acceptible for changing encryption state
which normally does not happen too often.
Can not recommend such technique for nbackup...



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [SPAM] Re: NBAK simplification RFC

Nikolay Samofatov
In reply to this post by Vlad Khorsun-2
Hello, Vlad!

On Mon, 2017-03-20 at 18:43 +0200, Vlad Khorsun wrote:
> > Another issue at play here is early "disk full" failure path during
> > CCH_mark rather then write_page, but I am not sure it really matters in
> > terms of possible database corruption - "careful write" should in theory
> > take care of things even if write_page fails due to "disk full"
> > condition.
>
>    Practice shows that careful write can't help there. And i failed to see how
> CW could help in case of out of disk condition for delta file, which contains
> pages not in database order.

Let me try to explain.

Careful write strategy can be explained as follows:
Database is changed by a sequence of atomic page write operations and
database and algorithms are designed in a way so that each IO operation
preserves consistency of database as a whole.
So we are dealing with ordered sequence of IO transactions posted during
cache flush operations (write_page).

When encountering write error proper handling would be to stop writing
any further pages in sequence (this could be slightly relaxed if
precedence is taken into account). This should guaranty that database
stays consistent when IO write fails for as long as last written state
is preserved.

Direction of write (delta file or main database file) is not important.
Only the sequence of IO transactions matters.

I explained what engine should have been doing to handle IO errors
properly. Engine does something else here (see it releases page locks on
IO errors in down_grade, for example). I do not understand why is it
doing what it does - maybe you can help my understanding here.

BTW, our "delta file" logic is not unique, so engine should handle it
properly. There are many filesystems (for example log-structured FS or
compressed FS or "write anywhere" FS like ZFS) that can fail with
out-of-disk space condition on random write.


Nikolay Samofatov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NBAK simplification RFC

Nikolay Samofatov
In reply to this post by Dmitry Yemanov-3
Dmitry, All,

On Mon, 2017-03-20 at 20:06 +0300, Dmitry Yemanov wrote:
> >> It also might be possible to use shared memory for synchronization
> >> instead of lock manager calls to speed things up.
> >
> >    Could you explain more ?
>
> I suppose Nickolay means replacing GlobalRWLock with native OS-level RW
> primitives used similar to shared memory mutexes. For Windows, they're
> just shared as named objects, for POSIX they're stored in shmem.

You are mostly correct.

However, for Windows we would have to roll our own sync objects that
would use shared memory, atomic ops and named objects (e.g. event).
SRWLock is for one process only unfortunately.

Nikolay Samofatov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Loading...