| 01:13.55 | *** join/#elinux djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) |
| 02:46.12 | *** join/#elinux roxfan (dunno@91.180.69.116) |
| 07:51.47 | *** join/#elinux unsigned (unsigned@pdpc/supporter/active/unsigned) |
| 07:52.08 | unsigned | anyone alive? |
| 07:54.43 | Russ | yes |
| 07:54.52 | Russ | I mean no |
| 07:54.58 | Russ | I mean, I'm a zombie |
| 07:55.14 | unsigned | Thats ok. zombies are cool |
| 07:55.23 | Russ | what the bible didn't tell you is that all those that get raptured, just their soul goes, their body remains on earth and seeks brains |
| 07:55.24 | unsigned | and useful .. as human shields :P |
| 07:56.07 | unsigned | does linux generate SIGPWR on regular power failure? |
| 07:56.18 | unsigned | or only if its on UPS backup? |
| 07:56.45 | unsigned | I'm workin on an embedded project and I want to flush my data when the power fails |
| 08:02.43 | Russ | I'm pretty sure SIGPWR is for when power is failing "soon" |
| 08:02.47 | Russ | not as we speak |
| 08:03.31 | unsigned | bah |
| 08:03.43 | Russ | that would be a very very short amount of time |
| 08:03.51 | unsigned | all i need is about 100ms |
| 08:03.59 | unsigned | to flush some data and close open files |
| 08:04.00 | Russ | and the races you'd get on false positives would probably be awful |
| 08:04.09 | unsigned | well its better than data corruption |
| 08:04.11 | Russ | when you are losing power is a really bad time to write data |
| 08:04.20 | Russ | horrible, horrible failure modes |
| 08:04.36 | Russ | its much better to STOP all writing when the power starts go go below spec |
| 08:04.44 | unsigned | hmm |
| 08:05.02 | unsigned | basically i just need to log the time the device lost power |
| 08:05.15 | unsigned | and some other tiny data |
| 08:06.17 | unsigned | my os partition is read only so thats safe |
| 08:06.41 | unsigned | but the data partition could get corrupted if i cant do the bookkeeping stuff |
| 08:13.18 | Russ | just realize that unless the system is designed very carefully, you could attempt to write to one area, but have it end up somewhere else |
| 08:13.32 | Russ | its a better bet to just put a periodic mark in |
| 08:14.13 | Russ | if its really really important to the system, I'd design it as a separate circuit with a special kind of very small memory |
| 08:14.49 | Russ | because you really don't want to log a poweroff event before the supervisory circuit decides to hold the system in reset |
| 08:15.00 | unsigned | well the primary function of the device is to record periodic data and then upload it upon request |
| 08:15.12 | Russ | why does it need to know when it lost power? |
| 08:15.45 | unsigned | so my user can know why the device didn't record any data |
| 08:15.51 | unsigned | for that time period |
| 08:17.16 | Russ | what other reason could there be except lost power? |
| 08:18.40 | unsigned | i poll the data over the serial port from another device and there are other scenarios where the data is unavailable |
| 08:19.28 | Russ | then can't you log that it is unavailable? |
| 08:23.26 | unsigned | but the data was available.. i just couldn't log it because the device wasn't up.. |
| 08:25.11 | unsigned | i was thinking of adding a add-on card for power backup but it also increases the cost, so wanted to know if I could cheat my way out |
| 08:25.59 | Russ | I'm still confused why there can't be some sort of "I'm here, but there is no data for me to log" message |
| 08:26.50 | unsigned | .. its the opposite.. "sorry i couldn't even check if there was any data to log because i was switched off" |
| 08:27.39 | Russ | right, but if there is a log message every 5 minutes, when you see a span of time where there are no log messages, just assume it was off |
| 08:28.06 | Russ | when it checks to see if there is data to log, and there is none, write an empty log message |
| 08:29.55 | unsigned | well the polling interval is user configurable and it can go down to 1/second, so i'd just end up creating huge files |
| 08:30.43 | Russ | just log the awake thing special, touch the log file |
| 08:30.57 | unsigned | but in any case.. it doesn't solve my main problem, which is to either close the file handle i hold, or flush data and close the handle |
| 08:31.01 | Russ | when you wake up and the log file is modified at a time newer than the last log message, log that fact |
| 08:31.19 | unsigned | to avoid corruption |
| 08:31.36 | Russ | It really depends on the filesystem, the mount options, and how much data you are logging |
| 08:31.53 | Russ | and the underlying media, and the underlying media controller, etc |
| 08:32.11 | Russ | why not flush after every log message? |
| 08:32.12 | unsigned | well before i get into that I was investigating ways to first detect the power failure itself |
| 08:32.18 | unsigned | so sigpwr is out i suppose |
| 08:34.49 | unsigned | its a amd geode lx 800 / cs5536 and currently i'm using ext2 for developing (media is CF) |
| 08:35.12 | Russ | ...are you aware of what CF is? |
| 08:35.21 | Russ | its a microcontroller running its own OS |
| 08:35.36 | unsigned | compact flash |
| 08:35.36 | unsigned | :S |
| 08:36.22 | Russ | so to know at which point in time a power loss will cause behavior a or behavior b is very difficult to know and will vary from manufacturer to manufacturer |
| 08:36.46 | Russ | if you do make a mini-ups, that would be a sure way to handle things, just understand the corner cases and difficulties |
| 08:37.02 | Russ | like after a power loss, do you wait until the battery is fully changed before powering back on? |
| 08:37.18 | Russ | if not, if there is a second power loss, will you have enough battery to shut down normally? |
| 08:37.45 | unsigned | well i'm still designing this device, so I have yet to commit to adding the ups |
| 08:41.10 | unsigned | one alternative I had in my mind was to use a transaction based FS |
| 08:41.42 | unsigned | but seeing as I have limited read/write cycles on my media, thats another thing I have to consider too |
| 09:48.45 | *** join/#elinux toi (~peter@94-226-59-90.access.telenet.be) |
| 10:06.05 | *** join/#elinux romerofilho (~bull@187.114.214.167) |
| 10:11.03 | *** part/#elinux romerofilho (~bull@187.114.214.167) |
| 10:35.25 | *** join/#elinux toi (~peter@94-226-59-90.access.telenet.be) |
| 11:46.42 | *** join/#elinux lyakh (~lyakh@dslb-094-221-113-071.pools.arcor-ip.net) |
| 13:26.41 | *** join/#elinux GPSFan (~kenm@64.92.145.112) |
| 13:27.32 | *** join/#elinux adyer (~adyer@c-67-167-224-31.hsd1.il.comcast.net) |
| 13:51.31 | *** join/#elinux toi (~peter@94-226-59-90.access.telenet.be) |
| 13:58.56 | *** join/#elinux gordon (~gd@122.96.138.147) |
| 14:30.43 | *** join/#elinux gordon3 (~gd@122.96.138.147) |
| 14:31.18 | *** join/#elinux gordon_ (~gd@122.96.138.147) |
| 14:44.14 | *** join/#elinux TimRiker (~timr@keri-pc.rikers.org) |
| 14:44.14 | *** join/#elinux TimRiker (~timr@bzflag/projectlead/TimRiker) |
| 14:44.14 | *** mode/#elinux [+o TimRiker] by ChanServ |
| 16:18.58 | *** join/#elinux djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) |
| 23:31.24 | *** join/#elinux [XeN] (~XeN]@brln-4db97aca.pool.mediaWays.net) |
| 23:38.18 | *** join/#elinux toi (~peter@94-226-59-90.access.telenet.be) |