[MacLoggerContest] Journalling

Wed Mar 2 19:06:16 EST 2005

I think I can help here...

Journalling on Mac OS X 10.3.x was introduced for two reasons. 1) It 
provides a more reliable way to recover from a unplanned computer 
shutdown (ie power was removed).  2) It greatly speeds the recovery 
process on reboot when this event occurs.

Previous to journaling the OS would have to scan the entire disk 
looking for and cleaning up directory structure on the disk(s) often 
called by UNIX name FSCK (File System Check).  This might be ok if your 
drive(s) are not very big, but now we have single ATA HDs that can be 
as big as 400 GB.  That could take a very long time (hours) to scan.

Also recall Apple makes very large RAID drives called Xserve RAID.  It 
can store up to about 5 TB (5,000 GB) in a single volume.  I am 
guessing but running a normal scan disk would take a few days on a 
volume this large and full of files. http://www.apple.com/xserve/raid/
Related .... Don't even think about defragmenting one of these at it 
would take a very very long time. Which is also why Mac OS X and UNIX 
in general is designed to overcome many file fragmentation issues and 
why background defrag is also built in (Only active when system thinks 
it really necessary and on file small subset if files).

As the name implies a journal is kept by the OS on when and where files 
where manipulated. Instead of scanning the disk after an improper 
shutdown it just checks the journal for what it was last doing and 
check those files.  It is not intended to actually save your files you 
were working on.  Much more reliable than having a program scanning 
everything and make best guess as what it suppose to look like. And 
your back up and running in seconds rather than minutes/hours/days 
depending on size and number of drives.

My suggestion is to avoid situation this if at all possible. How?  Use 
Laptops as they have built in UPS (battery). or get a UPS for Desktop 
with USB connection to communicate to your computer.  This way if you 
have a power out you can shut the system down cleanly.

A journalised database performs similar function, but specifically on 
the database records.  Many relational and SQL databases have this 
feature built in so it possible to get that function without really 
knowing about it as an operator.

I am not a contester myself yet but enjoy making contact with 
contesters! Enjoying the thoughts and conversations here too.

Hope this is of some help!

Steve - VA3SPH

On 2-Mar-05, at 2:41 PM, Jack Brindle wrote:

> A short bit of clarification, then. Make no assumptions as to what I 
> may be referring. I won't claim to know what problem journalling may 
> be solving. I won't claim to know how it may be solving that problem. 
> I won't even claim to know why Apple added journalling to the Mac's 
> file system!
>
> I simply want to know what the problem is that needs to be solved, and 
> apparently has been solved in the past with journalling.
>
> On Mar 2, 2005, at 10:46 AM, Jonathan G0DVJ wrote:
>
>>
>> Interesting discussion ...
>>
>> Are we mixing up two meanings of Journalling?  Maybe John mentioned 
>> it in the general sense of keeping a journal record of QSO data so 
>> that nothing is lost.  i.e. at the application level.  There is also 
>> the OSX specific meaning of Journalling which was introduced in 
>> Panther and which is a system-wide volume configuration aspect under 
>> admin user control at disk set-up time, and not the application.   
>> Not sure if Jack is alluding to this in his posting?
>>
>> I agree that the simplest way seems to be to write then flush from 
>> the application's viewpoint.  However maybe this is another area 
>> where we should just state what the user experience should be and 
>> leave it to Don to decide how best to implement things to achieve it, 
>> like Jack rightly pointed out when I mentioned multi-threading in an 
>> earlier post!
>>
>> I think we all agree with John's original point about losing nothing 
>> from the committed log - Most other systems I have used cannot 
>> guarantee that the current QSO still being entered (i.e. not 
>> completed/committed) won't be lost, but that is the most one can 
>> lose.
>>
>> 73,
>> Jonathan.
>> --
>>
>> On Mar 2, 2005, at 6:44 am, Jack Brindle wrote:
>>
>>>
>>> On Feb 28, 2005, at 1:56 PM, John Bastin wrote:
>>>
>>>> Automatic journaling, so even if you have a power failure, NOTHING 
>>>> is lost.
>>>
>>> This grabbed my attention - I'd like to drill into it a bit to 
>>> understand exactly what is being asked for and why. More 
>>> importantly, I want to understand the current need for journalling, 
>>> because I don't think I understand it properly now.
>>>
>>> Under MacOS X information written to files may be immediately 
>>> flushed to disk. When writing a log file, the data may be appended 
>>> to the log file and saved to disk immediately. As I understand 
>>> journalling, the information is written to the journal file, then to 
>>> the log file. In this case a power failure before the journal write 
>>> would lose the entry, while one in-between the two writes will 
>>> simply cause a journal-to-log file update on restart. But, the 
>>> information that would be appended to the log file could have been 
>>> handled in place of the journal write, taking care of the whole 
>>> thing at once. In both cases, power failures before the first write 
>>> completes causes the entire entry to be lost, while a failure after 
>>> the first write completes just causes the operator to be rather 
>>> unhappy.
>>>
>>> It seems that the simplest way to handle things would be to write 
>>> the log entry to the file and immediately flush the file to disk. Is 
>>> this too simple? What am I missing?
>>
>> _______________________________________________
>> MacLoggerContest mailing list
>> MacLoggerContest at dogparksoftware.com
>> http://seven.pairlist.net/mailman/listinfo/macloggercontest
>>
>>
>
> -Jack Brindle, W6FB
> =======================================================================
>
> _______________________________________________
> MacLoggerContest mailing list
> MacLoggerContest at dogparksoftware.com
> http://seven.pairlist.net/mailman/listinfo/macloggercontest
>
>
73
Steve
VA3SPH