MobileRead Forums - View Single Post - Keeping book on NAS but metadata.db on local (Ubuntu)

q345 · 05-26-2010, 08:04 PM

I think it goes circles and/or wrong direction.

The whole discussion was about placing e-books on NAS which is fairly reasonable considering people have large e-book libraries, want to access them across multiple computers/ over network and NAS is mainstream ( very exact reason why music collections are on NAS) People mentioned that one of the concerns what happens if metadata/ebooks got corrupted/got out of sync because they are placed in different places : metadata.db locally (because sqlite doesn't support NAS and for performance reason) and e-books on NAS.

I suggested a reasonable way to reduce penalty if it's happens (nothing new, just the same concept as with digital music files), which need to be implemented in such a way because of deficiencies of some of e-book formats).

I denoted that as a positive SIDE-EFFECT it also makes the whole scheme more robust because it simplify recovery if something wrong happens with metadata.db file REGARDLESS where it's located.

That's all point. The whole moto was NAS placement, not a reliability of metadata.db/sqlite (btw even very robust applications sometimes failed, sqlite include, so a little redundancy is OK I guess if doesn't cost a fortune/years to implement/maintain). I am perfectly fine with current scheme - it took me 30 seconds to put setenv OVERRIDE_METADATA in my .gnomerc - I am used to Unix/Linux so I can live without GUIs most of the time - no problem.

Of course since you've developed this product, you have infinitely better perspective on the whole issue. Regarding performance, I am new to Calibre and if people use it for many hours per day non-stop constantly modifying tags, then indeed additional read/write operations might degrade performance ( I have no idea for how much). My guess was ( and may be I am totally wrong) that overwhelming majority doesn't use Calibre in such a way, in that case performance degradation will be unnoticable.

Chaley was correct to mention that this scheme is not without shortcommings. Ideal ( and unrealistic ) solution would be that every e-book format will have a a place for metadata ( like digital music) and then the whole point became moot. Unfortunately it will not happen for a billion of technical and non-technical reasons

05-26-2010, 08:04 PM	#26
q345 Member Posts: 23 Karma: 10 Join Date: May 2010 Device: none	It's not about metadata it's about metadata & NAS I think it goes circles and/or wrong direction. The whole discussion was about placing e-books on NAS which is fairly reasonable considering people have large e-book libraries, want to access them across multiple computers/ over network and NAS is mainstream ( very exact reason why music collections are on NAS) People mentioned that one of the concerns what happens if metadata/ebooks got corrupted/got out of sync because they are placed in different places : metadata.db locally (because sqlite doesn't support NAS and for performance reason) and e-books on NAS. I suggested a reasonable way to reduce penalty if it's happens (nothing new, just the same concept as with digital music files), which need to be implemented in such a way because of deficiencies of some of e-book formats). I denoted that as a positive SIDE-EFFECT it also makes the whole scheme more robust because it simplify recovery if something wrong happens with metadata.db file REGARDLESS where it's located. That's all point. The whole moto was NAS placement, not a reliability of metadata.db/sqlite (btw even very robust applications sometimes failed, sqlite include, so a little redundancy is OK I guess if doesn't cost a fortune/years to implement/maintain). I am perfectly fine with current scheme - it took me 30 seconds to put setenv OVERRIDE_METADATA in my .gnomerc - I am used to Unix/Linux so I can live without GUIs most of the time - no problem. Of course since you've developed this product, you have infinitely better perspective on the whole issue. Regarding performance, I am new to Calibre and if people use it for many hours per day non-stop constantly modifying tags, then indeed additional read/write operations might degrade performance ( I have no idea for how much). My guess was ( and may be I am totally wrong) that overwhelming majority doesn't use Calibre in such a way, in that case performance degradation will be unnoticable. Chaley was correct to mention that this scheme is not without shortcommings. Ideal ( and unrealistic ) solution would be that every e-book format will have a a place for metadata ( like digital music) and then the whole point became moot. Unfortunately it will not happen for a billion of technical and non-technical reasons Last edited by q345; 05-26-2010 at 08:15 PM.