problems with digikam3.db into a nefs partition

Can someone confirm that?
http://qa.mandriva.com/show_bug.cgi?id=29061
If so I can fill a bug on bko recalling it.

Angelo

PS can it be fixed for 0.9.1 final by any chance?

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gerhard Kulzer]

Am Saturday 03 March 2007 schrieb Angelo Naselli:
> Can someone confirm that?
> http://qa.mandriva.com/show_bug.cgi?id=29061
> If so I can fill a bug on bko recalling it.
>
> Angelo
>
> PS can it be fixed for 0.9.1 final by any chance?

This is a long known sqlite incompatibility with nfs. It will certainly not be
fixed for 0.9.1, and cannot be fixed by us. Maybe we should build in some
check to give a warning, so that users know what's the problem.

Is there a bug filed with sqlite? I would guess so since the problem is the
same for all applications.

Gerhard

--
Hakuna matata
http://www.gerhard.fr

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Yes, the sqlite/NFS problem is know since a long time (look the SQlite FAQ from sqlite web project page).

 

I think than there is no issue with SQlite implementation about NFS.

 

There is plan for the future to solve the problem :

 

1/ add a "red" warning message in Album library path digiKam setting, like i have do with JPEG image saving settings. The message must be something like that : "Local path, not Remote path like NFS". Gerhard, it's easy to do. If you want to do it, just look how i have implemented the JPEG options widget here :

 

http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/jpegsettings.cpp?revision=634175&view=markup

 

2/ there is already an option with .configure script to place the database file outside the Album repository (the digikam3.db file is place in local home directory). But i'm not sure if this option work properlly. I have personaly never used NFS with digiKam. Also this way require to compile by hand digiKam & co to just use NFS.

 

3/ With the future QT4 port, we will create an universal DB frontend to use other DB backend than sqlite (like Amarock do).

 

Gilles

 

2007/3/4, Gerhard Kulzer <[hidden email]>:

Am Saturday 03 March 2007 schrieb Angelo Naselli:
> Can someone confirm that?
> http://qa.mandriva.com/show_bug.cgi?id=29061
> If so I can fill a bug on bko recalling it.
>
> Angelo
>
> PS can it be fixed for 0.9.1 final by any chance?

This is a long known sqlite incompatibility with nfs. It will certainly not be
fixed for 0.9.1, and cannot be fixed by us. Maybe we should build in some
check to give a warning, so that users know what's the problem.

Is there a bug filed with sqlite? I would guess so since the problem is the
same for all applications.

Gerhard

--
Hakuna matata
http://www.gerhard.fr

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/3/3, Angelo Naselli <[hidden email]>:

Can someone confirm that?
http://qa.mandriva.com/show_bug.cgi?id=29061
If so I can fill a bug on bko recalling it.

 

no need to fill a bug report. There is already one...

 

Angelo

PS can it be fixed for 0.9.1 final by any chance?

 

no. But look here :

 

http://thoughtsonrails.wordpress.com/2007/03/03/digikam-albums-on-network-filesystem/

 

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Alle 08:54, domenica 4 marzo 2007, Gilles Caulier ha scritto:

> Yes, the sqlite/NFS problem is know since a long time (look the SQlite FAQ
> from sqlite web project page).
>
> I think than there is no issue with SQlite implementation about NFS.
>
> There is plan for the future to solve the problem :
>
> 1/ add a "red" warning message in Album library path digiKam setting, like i
> have do with JPEG image saving settings. The message must be something like
> that : "Local path, not Remote path like NFS". Gerhard, it's easy to do. If
> you want to do it, just look how i have implemented the JPEG options widget
> here :

How about a nfs home? I mean in some system the homes are mounted by nfs to

have the same home for any machine.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Alle 14:02, domenica 4 marzo 2007, Gilles Caulier ha scritto:

> 2007/3/3, Angelo Naselli <[hidden email]>:
> >
> > Can someone confirm that?
> > http://qa.mandriva.com/show_bug.cgi?id=29061
> > If so I can fill a bug on bko recalling it.
>
>
> no need to fill a bug report. There is already one...
>
>
> Angelo
> >
> > PS can it be fixed for 0.9.1 final by any chance?
>
>
> no. But look here :
>
> http://thoughtsonrails.wordpress.com/2007/03/03/digikam-albums-on-network-filesystem/

if you can mount you can also avoid links ;) just mount under

~/Pictures/mntdir and should work.
But that doesn't solve the whole home mounted by nfs.... is that a problem as well?

Angelo

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Angelo,

 

this wil depand where is set the album library path. if home folder is hosted by NFS and if library is set on local, all will be fine.

 

The problem is about the digikam3.db file witch is placed at root folder of album library path. When you set a this one on a NFS mount point, sqlite will be lost to commit data on database placed on the network.

 

If you set your root album library in local, and if you create links to your NFS mount points where are placed pictures, this will work because the databse still in local.

 

Gilles  

 

2007/3/4, Angelo Naselli <[hidden email]>:

Alle 14:02, domenica 4 marzo 2007, Gilles Caulier ha scritto:

> 2007/3/3, Angelo Naselli <[hidden email]>:
> >
> > Can someone confirm that?
> > http://qa.mandriva.com/show_bug.cgi?id=29061
> > If so I can fill a bug on bko recalling it.
>
>
> no need to fill a bug report. There is already one...
>
>
> Angelo
> >
> > PS can it be fixed for 0.9.1 final by any chance?
>
>
> no. But look here :
>
> http://thoughtsonrails.wordpress.com/2007/03/03/digikam-albums-on-network-filesystem/

if you can mount you can also avoid links ;) just mount under
~/Pictures/mntdir and should work.
But that doesn't solve the whole home mounted by nfs.... is that a problem as well?

Angelo

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Alle 18:46, domenica 4 marzo 2007, Gilles Caulier ha scritto:

> Angelo,
>
> this wil depand where is set the album library path. if home folder is
> hosted by NFS and if library is set on local, all will be fine.
>
> The problem is about the digikam3.db file witch is placed at root folder of
> album library path. When you set a this one on a NFS mount point, sqlite
> will be lost to commit data on database placed on the network.
>
> If you set your root album library in local, and if you create links to your
> NFS mount points where are placed pictures, this will work because the
> databse still in local.

Shouldn't be the same (working) a scenario like that?

mount via nfs  ~/Pictures/mynfsmount
and leave the album ~/Pictures as a root for digikam3.db?


Angelo

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

yes it is...

 

Gilles

 

2007/3/4, Angelo Naselli <[hidden email]>:

Alle 18:46, domenica 4 marzo 2007, Gilles Caulier ha scritto:

> Angelo,
>
> this wil depand where is set the album library path. if home folder is
> hosted by NFS and if library is set on local, all will be fine.
>
> The problem is about the digikam3.db file witch is placed at root folder of
> album library path. When you set a this one on a NFS mount point, sqlite
> will be lost to commit data on database placed on the network.
>
> If you set your root album library in local, and if you create links to your
> NFS mount points where are placed pictures, this will work because the
> databse still in local.

Shouldn't be the same (working) a scenario like that?
mount via nfs  ~/Pictures/mynfsmount
and leave the album ~/Pictures as a root for digikam3.db?


Angelo

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

Hi,

Please, please, evaluate my proposal :
http://bugs.kde.org/show_bug.cgi?id=107871#c6

<<
I suggest to add 2 command-line options to start digikam.

* -f to to specify the full path to digikam3.db, or relative path from
the album directory

* directory as argument => this would be the album path digikam use

Eg:

1) # digikam
would behave like now. The 1st time, it will ask for an album path

2) # digikam -f /path/to/digikam3.db
would behave like now except it will use the specific path for the
database file

3) # digikam /path/to/my/album
digikam will use this directory as the album path, but won't override
default album path if there's already one

4) # digikam -f /path/to/digikam3.db /path/to/my/album
would combine 2) and 3)
 >>

This would not only be a workaround for the nfs/samba locking problem,
but also a way to extend digiKam's usage :
some people complain that they can only use one library which stores all
their pictures. They'd like to have a few libraries. There are also some
  people who'd like to access pictures on a read-only media (eg DVD).
Finally, some people would also like to open a specific directory which
contains pictures, like you can do with other tools.
All these wishes could be mostly solved by this addon...

Gilles Caulier wrote:

> Yes, the sqlite/NFS problem is know since a long time (look the SQlite
> FAQ from sqlite web project page).
>  
> I think than there is no issue with SQlite implementation about NFS.
>  
> There is plan for the future to solve the problem :
>  
> 1/ add a "red" warning message in Album library path digiKam setting,
> like i have do with JPEG image saving settings. The message must be
> something like that : "Local path, not Remote path like NFS". Gerhard,
> it's easy to do. If you want to do it, just look how i have implemented
> the JPEG options widget here :
>  
> http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/jpegsettings.cpp?revision=634175&view=markup 
> <http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/jpegsettings.cpp?revision=634175&view=markup>
>  
> 2/ there is already an option with .configure script to place the
> database file outside the Album repository (the digikam3.db file is
> place in local home directory). But i'm not sure if this option work
> properlly. I have personaly never used NFS with digiKam. Also this way
> require to compile by hand digiKam & co to just use NFS.
>  
> 3/ With the future QT4 port, we will create an universal DB frontend to
> use other DB backend than sqlite (like Amarock do).
>  

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Monday, 5. March 2007, Fabien wrote:

> Hi,
>
> Please, please, evaluate my proposal :
> http://bugs.kde.org/show_bug.cgi?id=107871#c6
>
> <<
> I suggest to add 2 command-line options to start digikam.
>
> * -f to to specify the full path to digikam3.db, or relative path from
> the album directory
>
> * directory as argument => this would be the album path digikam use
>
> Eg:
>
> 1) # digikam
> would behave like now. The 1st time, it will ask for an album path
>
> 2) # digikam -f /path/to/digikam3.db
> would behave like now except it will use the specific path for the
> database file
>
> 3) # digikam /path/to/my/album
> digikam will use this directory as the album path, but won't override
> default album path if there's already one
>
> 4) # digikam -f /path/to/digikam3.db /path/to/my/album
> would combine 2) and 3)
>  >>
>
> This would not only be a workaround for the nfs/samba locking problem,
> but also a way to extend digiKam's usage :
> some people complain that they can only use one library which stores all
> their pictures. They'd like to have a few libraries. There are also some
>   people who'd like to access pictures on a read-only media (eg DVD).
> Finally, some people would also like to open a specific directory which
> contains pictures, like you can do with other tools.
> All these wishes could be mostly solved by this addon...

I agree with your points 1-4.   Nevertheless from user point of
view having a warning when pictures are on a remote file system, like:

        Your picture library is on a remote file system.
        The digikam's database can't be stored there.
        Please spezify a local folder

                [Browse ...]    [Quit]

Is much more helpful.

Feel free to cut and paste to your bug report of post the bug# ;)

Achim

> Gilles Caulier wrote:
> > Yes, the sqlite/NFS problem is know since a long time (look the SQlite
> > FAQ from sqlite web project page).
> >  
> > I think than there is no issue with SQlite implementation about NFS.
> >  
> > There is plan for the future to solve the problem :
> >  
> > 1/ add a "red" warning message in Album library path digiKam setting,
> > like i have do with JPEG image saving settings. The message must be
> > something like that : "Local path, not Remote path like NFS". Gerhard,
> > it's easy to do. If you want to do it, just look how i have implemented
> > the JPEG options widget here :
> >  
> > http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/jpegsettings.cpp?revision=634175&view=markup 
> > <http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/jpegsettings.cpp?revision=634175&view=markup>
> >  
> > 2/ there is already an option with .configure script to place the
> > database file outside the Album repository (the digikam3.db file is
> > place in local home directory). But i'm not sure if this option work
> > properlly. I have personaly never used NFS with digiKam. Also this way
> > require to compile by hand digiKam & co to just use NFS.
> >  
> > 3/ With the future QT4 port, we will create an universal DB frontend to
> > use other DB backend than sqlite (like Amarock do).
> >  
>
> --
> Fabien
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>

--
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- [hidden email]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/3/6, Achim Bohnet <[hidden email]>:

On Monday, 5. March 2007, Fabien wrote:
> Hi,
>
> Please, please, evaluate my proposal :
> http://bugs.kde.org/show_bug.cgi?id=107871#c6
>

> <<
> I suggest to add 2 command-line options to start digikam.
>
> * -f to to specify the full path to digikam3.db, or relative path from
> the album directory
>
> * directory as argument => this would be the album path digikam use
>
> Eg:
>
> 1) # digikam
> would behave like now. The 1st time, it will ask for an album path
>
> 2) # digikam -f /path/to/digikam3.db
> would behave like now except it will use the specific path for the
> database file
>
> 3) # digikam /path/to/my/album
> digikam will use this directory as the album path, but won't override
> default album path if there's already one
>
> 4) # digikam -f /path/to/digikam3.db /path/to/my/album
> would combine 2) and 3)
>  >>
>
> This would not only be a workaround for the nfs/samba locking problem,
> but also a way to extend digiKam's usage :
> some people complain that they can only use one library which stores all
> their pictures. They'd like to have a few libraries. There are also some
>   people who'd like to access pictures on a read-only media (eg DVD).
> Finally, some people would also like to open a specific directory which
> contains pictures, like you can do with other tools.
> All these wishes could be mostly solved by this addon...

I agree with your points 1-4.   Nevertheless from user point of
view having a warning when pictures are on a remote file system, like:

        Your picture library is on a remote file system.
        The digikam's database can't be stored there.
        Please spezify a local folder

                [Browse ...]    [Quit]

Is much more helpful.

Feel free to cut and paste to your bug report of post the bug# ;)

Achim

Yes Achim, something like this must be done on GUI.

Just a notice about SQlite and NFS. On LinuxFR.org forum (in French), an user have reported than SQLite work fine with NFS version >= 4. NFS 3 do not work.

Look this link : http://linuxfr.org/2007/03/06/22160.html

If there is somebody witch have an NFS4 server ready to use with digiKam, i would to have a fresh report about this point... Take a care to test, i recommend to use a test account with a fresh album library path. Do not try to use it in production because there is a risk to corrupted the database.

Gilles


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

Hello,

Achim Bohnet wrote:

> On Monday, 5. March 2007, Fabien wrote:
>
>>Hi,
>>
>>Please, please, evaluate my proposal :
>>http://bugs.kde.org/show_bug.cgi?id=107871#c6
>>
>><<
>>I suggest to add 2 command-line options to start digikam.
>>
>>* -f to to specify the full path to digikam3.db, or relative path from
>>the album directory
>>
>>* directory as argument => this would be the album path digikam use
>>
>>Eg:
>>
>>1) # digikam
>>would behave like now. The 1st time, it will ask for an album path
>>
>>2) # digikam -f /path/to/digikam3.db
>>would behave like now except it will use the specific path for the
>>database file
>>
>>3) # digikam /path/to/my/album
>>digikam will use this directory as the album path, but won't override
>>default album path if there's already one
>>
>>4) # digikam -f /path/to/digikam3.db /path/to/my/album
>>would combine 2) and 3)
>> >>
>>
>>This would not only be a workaround for the nfs/samba locking problem,
>>but also a way to extend digiKam's usage :
>>some people complain that they can only use one library which stores all
>>their pictures. They'd like to have a few libraries. There are also some
>>  people who'd like to access pictures on a read-only media (eg DVD).
>>Finally, some people would also like to open a specific directory which
>>contains pictures, like you can do with other tools.
>>All these wishes could be mostly solved by this addon...
>
>
> I agree with your points 1-4.   Nevertheless from user point of
> view having a warning when pictures are on a remote file system, like:
>
> Your picture library is on a remote file system.
> The digikam's database can't be stored there.
> Please spezify a local folder
>
> [Browse ...]    [Quit]
>
> Is much more helpful.

Well, yes it could be useful, but doesn't solve the problem :)
Note: "can't" is not the best word. It can work perfectly fine, even on
a remove fs.

> Feel free to cut and paste to your bug report of post the bug# ;)

There's a warning in the configuration page. But, I guess the same
warning could be added the first time digiKam is started, when it asks
for an album library path.

And, about my proposal, don't forget it's not only about this locking
problem, it's also about adding requested features...
I'm sure digiKam loses a lot of users because of the different use cases
I mentionned above that digiKam doesn't address right now.
IMHO, it's really a pity...

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

Gilles Caulier wrote:

>
> Just a notice about SQlite and NFS. On LinuxFR.org forum (in French), an
> user have reported than SQLite work fine with NFS version >= 4. NFS 3 do
> not work.
>
> Look this link : http://linuxfr.org/2007/03/06/22160.html 
> <http://linuxfr.org/2007/03/06/22160.html>
>
> If there is somebody witch have an NFS4 server ready to use with
> digiKam, i would to have a fresh report about this point... Take a care
> to test, i recommend to use a test account with a fresh album library
> path. Do not try to use it in production because there is a risk to
> corrupted the database.

Well, I'd like to test it, but I must confess I can't reproduce the
problem, even with a linux NFS server (nfsv3).
When I try, it works perfectly :)
When does an error occur ?

I tried to import pictures, add comments, edit,... : everything is ok.

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Try to stress the database using a large taging image/comment or rating. The problem apprears about multiple access on DB duing a wrong DB lock.

If you take a look into SQlite FAQ, you can read :

Q : Can multiple applications or multiple instances of the same application access a single database file at the same time?

R: Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
SQLite uses reader/writer locks to control access to the database. (Under Win95/98/ME which lacks support for reader/writer locks, a probabilistic simulation is used instead.) But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time. On Windows, Microsoft's documentation says that locking may not work under FAT filesystems if you are not running the Share.exe daemon. People who have a lot of experience with Windows tell me that file locking of network files is very buggy and is not dependable. If what they say is true, sharing an SQLite database between two or more Windows machines might cause unexpected problems.
We are aware of no other embedded SQL database engine that supports as much concurrancy as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.
However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.
When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions."

Gilles

2007/3/7, Fabien <[hidden email]>:

Gilles Caulier wrote:
>
> Just a notice about SQlite and NFS. On LinuxFR.org forum (in French), an
> user have reported than SQLite work fine with NFS version >= 4. NFS 3 do
> not work.
>
> Look this link : http://linuxfr.org/2007/03/06/22160.html
> <http://linuxfr.org/2007/03/06/22160.html >
>
> If there is somebody witch have an NFS4 server ready to use with
> digiKam, i would to have a fresh report about this point... Take a care
> to test, i recommend to use a test account with a fresh album library
> path. Do not try to use it in production because there is a risk to
> corrupted the database.

Well, I'd like to test it, but I must confess I can't reproduce the
problem, even with a linux NFS server (nfsv3).
When I try, it works perfectly :)
When does an error occur ?

I tried to import pictures, add comments, edit,... : everything is ok.

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

Hi,

Gilles Caulier wrote:
> Try to stress the database using a large taging image/comment or rating.
> The problem apprears about multiple access on DB duing a wrong DB lock.

I tried, but without success :) I even tried to update comments/tags
while copying images, did the same with 2 instances of digiKam.
I managed to make digiKam crash once, but didn't have troubles with sqlite !

> If you take a look into SQlite FAQ, you can read :
 > [...]

Yes, I already read it...

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/3/7, Fabien <[hidden email]>:

Hi,

Gilles Caulier wrote:
> Try to stress the database using a large taging image/comment or rating.
> The problem apprears about multiple access on DB duing a wrong DB lock.

I tried, but without success :) I even tried to update comments/tags
while copying images, did the same with 2 instances of digiKam.
I managed to make digiKam crash once, but didn't have troubles with sqlite !

Perhaps the SQLite/NFS problem ios relevant of NFS deamon settings or about to set on the NFSLock deamon at the same time than NFSd ?

Gilles
 

> If you take a look into SQlite FAQ, you can read :
> [...]

Yes, I already read it...

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

Gilles Caulier wrote:

>
>
> 2007/3/7, Fabien <[hidden email]
> <mailto:[hidden email]>>:
>
>     Hi,
>
>     Gilles Caulier wrote:
>      > Try to stress the database using a large taging image/comment or
>     rating.
>      > The problem apprears about multiple access on DB duing a wrong DB
>     lock.
>
>     I tried, but without success :) I even tried to update comments/tags
>     while copying images, did the same with 2 instances of digiKam.
>     I managed to make digiKam crash once, but didn't have troubles with
>     sqlite !
>
>
> Perhaps the SQLite/NFS problem ios relevant of NFS deamon settings or
> about to set on the NFSLock deamon at the same time than NFSd ?

Well, I use my own compiled linux kernel with kernel-based nfs server
(same for lockd)...
I don't have any specific settings.
But I read in sqlite mailing list archives that some people have
troubles when mixing freebsd server and linux clients...

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

ok

In all case i think than using a NFS mount point like a root album library path is wrong, because there is a risk to have 2 instance of digiKAm running on 2 different computers witch open the database in R/W. In this case, the concurrent writting on DB will corrupt the data.

The database file must be stored in all case in local. The way to have a link on NFS mount path like a subfolder of the root album library path is an easy solution. each computer have a dedicaced database file in local. No problem with NFS, no concurrent acess to DB.

Gilles

2007/3/7, Fabien <[hidden email]>:

Gilles Caulier wrote:

>
>
> 2007/3/7, Fabien <[hidden email]
> <mailto:[hidden email] >>:
>
>     Hi,
>
>     Gilles Caulier wrote:
>      > Try to stress the database using a large taging image/comment or
>     rating.
>      > The problem apprears about multiple access on DB duing a wrong DB
>     lock.
>
>     I tried, but without success :) I even tried to update comments/tags
>     while copying images, did the same with 2 instances of digiKam.
>     I managed to make digiKam crash once, but didn't have troubles with
>     sqlite !
>
>
> Perhaps the SQLite/NFS problem ios relevant of NFS deamon settings or
> about to set on the NFSLock deamon at the same time than NFSd ?

Well, I use my own compiled linux kernel with kernel-based nfs server
(same for lockd)...
I don't have any specific settings.
But I read in sqlite mailing list archives that some people have
troubles when mixing freebsd server and linux clients...

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gerhard Kulzer]

Am Wednesday 07 March 2007 schrieb Gilles Caulier:
> Try to stress the database using a large taging image/comment or rating.
> The problem apprears about multiple access on DB duing a wrong DB lock.
>
I tried and digikam crashes with "sqlite step error: unable to open database
on query: REPLACE INTO Images..." using nfs4 before really opening (during th
inital scan). nfs was mounted as root library.

So I think it must depend on the daemon settings if it works for others.

Gerhard

--
Hakuna matata
http://www.gerhard.fr

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel