[RomNexus6]

Hello,

to be used in domestic scenarios, the PI+XMBC needs to be able to be switched off without worrying about shutdown.
This is a must if you want your wife to use it without risk of breaking it at first use...

Proposal

To be able to switch off safetely we need to solve some problems.

1) Linux uses the FS for paging
2) Applications write on FS without worrying about poweroff during this procedure
3) in case of FAT, lost clusters are generated
4) SD card FS is maybe not reliable for powering down and preserving data
5) other?

1) we can build Linux without paging. Maybe it's already this way. I admit I didn't have a look at sources.

2) xmbc must take care of power off during write access. This can be done for every file touched, following this simple algorithm:

- firstly rename the old file to another name (e.g.: bak o whatever else)
- save the new file
- delete the bak

at loading:
- if bak doesn't exist: load the master file
- if bak exists: delete the master one, rename bak to master then load the master file

3) checkdisk must be take in place at every startup

4) in case of physical/technical big problems not easily solveable, it could be useful to allow XMBC to save database files directly on the USB media connected and not on SD

5) anything else?

What do you think?

[Memphiz]

Thats complete BS - sorry mate.

[RomNexus6]

other way (less smelly) to achieve it?

[caravela]

do you mean power failure of shutdown
there is no problems for the shutdown part, and for power failure all major distros use ext4 and use safe mount options to prevent data loss, it as safe as it can be. just connect the pi to the usb of the tv and it should power on/off every time you turn the tv on/off

[Ned Scott]

do you mean power failure of shutdown
there is no problems for the shutdown part, and for power failure all major distros use ext4 and use safe mount options to prevent data loss, it as safe as it can be. just connect the pi to the usb of the tv and it should power on/off every time you turn the tv on/off

XBMC should always be closed properly or the databases will get corrupt.

[caravela]

do you mean power failure of shutdown
there is no problems for the shutdown part, and for power failure all major distros use ext4 and use safe mount options to prevent data loss, it as safe as it can be. just connect the pi to the usb of the tv and it should power on/off every time you turn the tv on/off

XBMC should always be closed properly or the databases will get corrupt.

yeah true. Then again i just run it mostelly as streaming client

[RomNexus6]

as written in the first post, for databases corruption there could be a workaround, to be implemented inside database save and load functions.

1- firstly rename the database file to another name (e.g.: bak o whatever else). note: rename is atomic
2- save the new file
3- delete the bak

at loading:
- if bak doesn't exist: powerdown occured outside 1,2,3. load the database file as usual
- if bak exists: powerdown occured between 1-3. the bak is always valid (no one touched it). so delete the database file (maybe partially saved), rename bak to database then load the database file as usual

note: this is an usual algorithm for embedded industrial systems. I used it very often successfully.

[Memphiz]

You ever tried this "algorithm" on io lame sdcard with 200 db accesses a second? Beside that - on a powerfailure or whatever "rename is atomic" will never be true. The journaling of ext4 is the best you can get - and it won't help on power-off during sqlite actions.

Your algorithm would slow down the pi to a crawl. (beside that nobody would ever implement this because it just wouldn't work with files. Something like that might work on embedded eeproms were you write some bytes directly - not on an abstracted layer like the filesystem implementations in a linux system).

[RomNexus6]

for high number of files is not convenient.
and database uses a lot of files.

and what about a redundancy save at database level?
always save 2 databases: if one gets corrupted load the second one then delete the first.

[Memphiz]

Are you familiar with sqlite? Its 1 file. But you have a lot io (read/write) there. Its not the matter of the number of files but a matter of the number of i/o operations. And you suggest to move around/backup the file on each i/o operation (just imagine what this means when scraping your movie database and add about 100 movie metadata into 10 tables of 1 db where each transaction results in maybe 50 i/o operations on filesystem level).

I'll stop it here.

[RomNexus6]

it seems that sqlite already implements what I described (and many many more) with "rollback mode".

http://www.sqlite.org/atomiccommit.html

maybe it worth a try.
if already so, the database corruption problem lies somewhere else.