 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Just how big can a SD logfile be?
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
As per thread title. MM+ I know you can use cards up to 64GB in size, but my concern is file SIZE. I have a system that opens a file for append whenever something happens on the system, and it is logged with the date and time for future reference, debugging, or security(say someone repeatedly tries to enter the wrong password - this is all logged) At the moment, this is not a problem, but once the system is on-line, this file could grow quite large over time, and I want to know what limits there are with respect to MMBASIC being able to append to the file. The file is only EVER appended to, and only EVER one line of text as a log entry per attempt, so not trying to log heaps of information. Reading back is done on a page-by-page(on the LCD) arrangement, so MMBASIC only need to be able to access the file at all, and read 30 or so lines from it each time the user asks for another page on the LCD. ...all very straightforward and plain... But lets say that file grew over time to be 2GB... Or 4GB.... Are the file-size limits that MMBASIC can access just set by the file-system limits itself? IE: If you are using a FAT16 formatted card, the maximum file-size would be about 2GB, or 4GB if you are using FAT32 - is it as simple as that? My concern is overreaching what MMBASIC can actually handle in terms of file SIZE. EDIT: From time to time, this file WILL be copied across to an external backup, and the original file will PROBABLY be deleted to make way for a new one. I don't expect this to happen more then a couple of times per year though. I am also considering having monthly logfiles, which are auto-generated by the system each month, that way, filesize becomes something of a non-issue. I would have to re-write some code that is working fine to accommodate this, but I may well do just that. Several small files are less of a disaster then one big file if it gets corrupted. Several small files means you should be able to recover SOME of the log. If a gigantic logfile gets corrupted, you might not be able to recover ANY of it(easily, that is). Food for thought. Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5909 |
I would certainly rotate the logs monthly at least for all the reasons you gave in the edit. If the files are small enough, you could transfer them using xmodem without having to take a week to do it. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Yes, I think I agree with you. It was only as I was typing the post, then made the edit about the monthly logs that I started to think that having a big log - even if it is allowed - might not be the smartest move, should the big log get corrupted.... I already have the system create new logfiles for daily activity, and this is done automatically, so I will do a variation of that concept I think. Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
