Comments on: Key Limits Of Apple’s Time Machine http://storagemojo.com/2006/08/09/key-limits-of-apples-time-machine/ Data storage info & analysis Fri, 21 Nov 2008 21:36:33 +0000 http://wordpress.org/?v=2.6.3 By: PJ http://storagemojo.com/2006/08/09/key-limits-of-apples-time-machine/#comment-5426 PJ Tue, 15 Aug 2006 15:18:07 +0000 http://storagemojo.com/?p=214#comment-5426 | PJ, now I am getting confused. If journaling is used to create the disk image as it was at some point in time, why does Time Machine specify that it does backups at midnight? Because storing all the changepoints is much more expensive than storing some of them, so it would save a lot of journal space to consolidate all the changes made in some time period (a day?) into one change set. If in a 5 minute period you change A to a to b to B, that could be stored as either 3 changes ( A->a->b->B) or as one (A->B). One changeset is going to be much smaller than 3, and if there's a way to access that timepoint, or even just view the filesystem as it was at that timepoint, you've got a good way to make sure you get a consistent view of the filesystem, which is a prereq for doing a good backup. |A journaled file system - unlike the journaling done in a database - does not equal Continuous Data Protection or snapshot copy - because if it did we wouldn’t need CDP or snapshots. Sure - those features take some extra work, but a journaled filesystem provides all the information and facilites needed to implement CDP or snapshots, and I suspect that Time Machine is Apple's version of those kind of features; as usual though, the interface is the problem, and that's one place Apple excells. | PJ, now I am getting confused. If journaling is used to create the disk image as it was at some point in time, why does Time Machine specify that it does backups at midnight?

Because storing all the changepoints is much more expensive than storing some of them, so it would save a lot of journal space to consolidate all the changes made in some time period (a day?) into one change set. If in a 5 minute period you change A to a to b to B, that could be stored as either 3 changes ( A->a->b->B) or as one (A->B). One changeset is going to be much smaller than 3, and if there’s a way to access that timepoint, or even just view the filesystem as it was at that timepoint, you’ve got a good way to make sure you get a consistent view of the filesystem, which is a prereq for doing a good backup.

|A journaled file system - unlike the journaling done in a database - does not equal Continuous Data Protection or snapshot copy - because if it did we wouldn’t need CDP or snapshots.

Sure - those features take some extra work, but a journaled filesystem provides all the information and facilites needed to implement CDP or snapshots, and I suspect that Time Machine is Apple’s version of those kind of features; as usual though, the interface is the problem, and that’s one place Apple excells.

]]> By: Robert Pearson http://storagemojo.com/2006/08/09/key-limits-of-apples-time-machine/#comment-5170 Robert Pearson Fri, 11 Aug 2006 03:31:32 +0000 http://storagemojo.com/?p=214#comment-5170 I believe Time Machine is a wonderful product for the Personal Computer working environment. It is actually better than it needs to be. Over time it should improve. Provided Apple continues to be as responsive to user feedback as they have been. The visual frontend is very similar to a product called Scope I evaluated years ago. The UX (User Experience) was fantastic. Scope visualized all your files. It also sent copies of all of them back to the author without your permission. At least the eval did. Unfortunately Scope relied on Microsoft Outlook, which is a pig you don't want to plan your dreams on. I once was rejected in a job interview over the journaling vs. non-journaling question. When I was asked why you would want to use a journaling file system I gave a reply very much like ZDigital. The face of the VP of Technology I was interviewing went blank. He closed my paperwork and thanked me for coming in. I thought I had the job! When I asked him when I should report he looked at me like I was a complete fool. When I asked him how he would answer the question he almost screamed at me, "Because it doesn't have to run fsck!!!". Many people believe this to be the case. It is an obvious feature. This company was out of business in less than 3 years after this. Nice guys, not a clue. Think about 24x7xForever-Forever operations. If you reboot, it is true you would like to avoid the lengthy fsck. You pray to God that you don't have to reboot. But if you do, you hope that some form of "checkpointing" is available. Corrupted Information is a special problem. There are many kinds of corruption. The worst is from hardware failure. The corruption can be massive and undetected until reboot. It is hard to diagnose because there is no easily discernible pattern to it. FSCK can choke on these errors. Journaling seems to handle it better. Just an opinion. Nothing is foolproof. I believe Time Machine is a wonderful product for the Personal Computer working environment. It is actually better than it needs to be. Over time it should improve. Provided Apple continues to be as responsive to user feedback as they have been.
The visual frontend is very similar to a product called Scope I evaluated years ago. The UX (User Experience) was fantastic. Scope visualized all your files. It also sent copies of all of them back to the author without your permission. At least the eval did. Unfortunately Scope relied on Microsoft Outlook, which is a pig you don’t want to plan your dreams on.

I once was rejected in a job interview over the journaling vs. non-journaling question. When I was asked why you would want to use a journaling file system I gave a reply very much like ZDigital.
The face of the VP of Technology I was interviewing went blank. He closed my paperwork and thanked me for coming in. I thought I had the job! When I asked him when I should report he looked at me like I was a complete fool. When I asked him how he would answer the question he almost screamed at me, “Because it doesn’t have to run fsck!!!”. Many people believe this to be the case. It is an obvious feature. This company was out of business in less than 3 years after this. Nice guys, not a clue.

Think about 24×7xForever-Forever operations. If you reboot, it is true you would like to avoid the lengthy fsck. You pray to God that you don’t have to reboot. But if you do, you hope that some form of “checkpointing” is available.
Corrupted Information is a special problem. There are many kinds of corruption. The worst is from hardware failure. The corruption can be massive and undetected until reboot. It is hard to diagnose because there is no easily discernible pattern to it. FSCK can choke on these errors. Journaling seems to handle it better. Just an opinion. Nothing is foolproof.

]]> By: ZDigital http://storagemojo.com/2006/08/09/key-limits-of-apples-time-machine/#comment-5155 ZDigital Thu, 10 Aug 2006 21:04:22 +0000 http://storagemojo.com/?p=214#comment-5155 I thought the main purpose of a journaling filesystem was to provide consistency in the filesystem by checking a list of transactions and then rolling forward uncommitted transactions to the disk after a system crash. This was to prevent uncommitted data from being lost in the event of a power failure, crash, etc. which is what traditional filesystems were doing before journaling. To my way of thinking, Time Machine, sounds more like rsync or even a simplified Subversion repository and if Apple is using the Journaling function of HFS+ there must be a separate log that contains the transactions so that you can go back much further in time. As I have read, the log for a traditional Journaling FS is circular and has a limited length of life and would not be well suited to Time Machine. Let me know your thoughts. I thought the main purpose of a journaling filesystem was to provide consistency in the filesystem by checking a list of transactions and then rolling forward uncommitted transactions to the disk after a system crash. This was to prevent uncommitted data from being lost in the event of a power failure, crash, etc. which is what traditional filesystems were doing before journaling. To my way of thinking, Time Machine, sounds more like rsync or even a simplified Subversion repository and if Apple is using the Journaling function of HFS+ there must be a separate log that contains the transactions so that you can go back much further in time. As I have read, the log for a traditional Journaling FS is circular and has a limited length of life and would not be well suited to Time Machine. Let me know your thoughts.

]]> By: Robin Harris http://storagemojo.com/2006/08/09/key-limits-of-apples-time-machine/#comment-5148 Robin Harris Thu, 10 Aug 2006 18:06:16 +0000 http://storagemojo.com/?p=214#comment-5148 PJ, now I am getting confused. If journaling is used to create the disk image as it was at some point in time, why does Time Machine specify that it does backups at midnight? A journaled file system - unlike the journaling done in a database - does not equal Continuous Data Protection or snapshot copy - because if it did we wouldn't need CDP or snapshots. I think the Apple Knowledge Base article I quoted is correct: HFS+ journaling accelerates recovery time by eliminating the need for a lengthy fsck of the file system. PJ, now I am getting confused. If journaling is used to create the disk image as it was at some point in time, why does Time Machine specify that it does backups at midnight?

A journaled file system - unlike the journaling done in a database - does not equal Continuous Data Protection or snapshot copy - because if it did we wouldn’t need CDP or snapshots. I think the Apple Knowledge Base article I quoted is correct: HFS+ journaling accelerates recovery time by eliminating the need for a lengthy fsck of the file system.

]]> By: PJ http://storagemojo.com/2006/08/09/key-limits-of-apples-time-machine/#comment-5129 PJ Thu, 10 Aug 2006 06:20:09 +0000 http://storagemojo.com/?p=214#comment-5129 Journalling fits in because if you've got a starting point disk image and a journal that's a timestamped list of what changed on that image, you then have the ability to pick a point in the timeperiod that your journal covers and recreate the disk image as it was at that point in time. This is also related to how the big filer companies offer a way to be able to back up rapidly-changing files in a coherent fashion... they pick a time in the journal of that file and make that version available. Journalling fits in because if you’ve got a starting point disk image and a journal that’s a timestamped list of what changed on that image, you then have the ability to pick a point in the timeperiod that your journal covers and recreate the disk image as it was at that point in time. This is also related to how the big filer companies offer a way to be able to back up rapidly-changing files in a coherent fashion… they pick a time in the journal of that file and make that version available.

]]>