Journaled Hard Drive

• Journaled Hard Drive
• What Is A Journaled Hard Drive

Disk Utility

Disk Utility is a disk utility on macOS operating system. It supports creating, splitting, merging, resizing, deleting and formatting partitions on the hard disk. Disk Utility only supports partition creation and formatting for Mac OS Extended (Journaled), exFAT, MS-DOS (FAT) and since MacOS High Sierra (10.13), it supports APFS.

Rakesh Shewale writes with a common question about formatting compatibility: I bought a new external HDD for my mac about a month ago and formatted it to Mac OS X Extended Journaled. How to Format a Hard Drive for Windows 10. Note: Formatting your drive will erase all the existing files on it. So if your external hard drive already has important files on it, make sure to back them up before proceeding. Connect your external hard drive to a Windows computer. If your external hard drive is working, your computer will.

If you are a Linux user or operating systems other than macOS, you probably use another tool. In another case, if you are using a Seagate, WD My Passport or any other hard drive that you previously partitioned with another tool. Disk Utility will report MediaKit reports not enough space on device for requested operation. This error occurs because the partitions created do not comply with Apple's partition policy. In this case, you can use other tools instead of Disk Utility.

In this article, I will guide you to create a Mac OS Extended (Journaled) partition with GParted. If you want to install macOS High Sierra or later versions, just use the Convert to APFS feature on Disk Utility. Adobe fuse cc 2019 crack.

GParted

GParted is a well known disk partitioning program. It supports many partition formats such as FAT32, NTFS, exFAT, Ext4 and of course supports Mac OS Extended. We can use GParted to create Mac OS Extended partitions in just a few simple steps.

GParted comes pre-installed on many Linux distributions like Ubuntu, Debian, Linux Mint… If you already have GParted installed, just use it. If not, you can download GParted or 4MParted ISO files then integrate into AIO Boot. You should use these two operating systems, as they have pre-installed programs that support the format. If you use GParted on Ubuntu, Linux Mint or Debian, you need to install hfsprogs.

The format of Mac OS Extended is HFS+. There are some commercial softwares that support creating HFS + partitions on Windows, but GParted is free. Now we will create the HFS+ partition with GParted.

1. Run GParted and select the hard disk in the dropdown list at the top right. My hard disk is /dev/sda.
2. You can only create new partitions if your hard disk has unallocated space. Right-click on the unallocated space and select New. You can also format existing partitions to HFS+. Right-click the existing partition, select Format to, and then select hfs+. Or delete the existing partition to recreate it.
3. Select hfs+ in the File system. Then select and enter some information for the other items you want.
4. Click Add, then click Apply to apply the changes.

The Mac OS Extended partition created by GParted will not be journaled. However, we can use Disk Utility to Enable Journaling. Or use the following command to format Mac OS Extended to Mac OS Extended (Journaled):

/dev/sdaX is the partition you want to format.

Convert to APFS

From the MacOS High Sierra version, Apple announced a new file system called APFS. By default, macOS High Sierra can only be installed on an APFS partition. You can use Disk Utility to convert Mac OS Extended partitions to APFS without losing data.

If the Mac OS Extended partition is not Journaled, please journaled it first. Run Disk Utility, select the Mac OS Extended partition in the left column, then select File and select Enable Journaling.

Now you can convert Mac OS Extended (Journaled) partitions to APFS without losing data. Just select Edit and select Convert to APFS…

By using GParted with the simple steps above, we can easily create Mac OS Extended (Journaled) partitions and many other formats that Disk Utility does not support. If you need to create macOS High Sierra bootable USB from Windows, you can try Clover Boot Disk. Good luck!

A journaling file system is a file system that keeps track of changes not yet committed to the file system's main part by recording the intentions of such changes in a data structure known as a 'journal', which is usually a circular log. In the event of a system crash or power failure, such file systems can be brought back online more quickly with a lower likelihood of becoming corrupted.^[1][2]

Depending on the actual implementation, a journaling file system may only keep track of stored metadata, resulting in improved performance at the expense of increased possibility for data corruption. Alternatively, a journaling file system may track both stored data and related metadata, while some implementations allow selectable behavior in this regard.^[3]

History[edit]

In 1990 IBM JFS, introduced with AIX 3.1, was one of the first UNIX commercial filesystems that implemented journaling. This was subsequently implemented in Microsoft's Windows NT's NTFS filesystem in 1993 and in Linux's ext3 filesystem in 2001.^[4]

Rationale[edit]

Updating file systems to reflect changes to files and directories usually requires many separate write operations. This makes it possible for an interruption (like a power failure or system crash) between writes to leave data structures in an invalid intermediate state.^[1]

For example, deleting a file on a Unix file system involves three steps:^[5]

1. Removing its directory entry.
2. Releasing the inode to the pool of free inodes.
3. Returning all disk blocks to the pool of free disk blocks.

If a crash occurs after step 1 and before step 2, there will be an orphaned inode and hence a storage leak; if a crash occurs between steps 2 and 3, then the blocks previously used by the file cannot be used for new files, effectively decreasing the storage capacity of the file system. Re-arranging the steps does not help, either. If step 3 preceded step 1, a crash between them could allow the file's blocks to be reused for a new file, meaning the partially deleted file would contain part of the contents of another file, and modifications to either file would show up in both. On the other hand, if step 2 preceded step 1, a crash between them would cause the file to be inaccessible, despite appearing to exist.

Detecting and recovering from such inconsistencies normally requires a complete walk of its data structures, for example by a tool such as fsck (the file system checker).^[2] This must typically be done before the file system is next mounted for read-write access. If the file system is large and if there is relatively little I/O bandwidth, this can take a long time and result in longer downtimes if it blocks the rest of the system from coming back online.

To prevent this, a journaled file system allocates a special area—the journal—in which it records the changes it will make ahead of time. After a crash, recovery simply involves reading the journal from the file system and replaying changes from this journal until the file system is consistent again. The changes are thus said to be atomic (not divisible) in that they either succeed (succeeded originally or are replayed completely during recovery), or are not replayed at all (are skipped because they had not yet been completely written to the journal before the crash occurred).

Techniques[edit]

Some file systems allow the journal to grow, shrink and be re-allocated just as a regular file, while others put the journal in a contiguous area or a hidden file that is guaranteed not to move or change size while the file system is mounted. Some file systems may also allow external journals on a separate device, such as a solid-state drive or battery-backed non-volatile RAM. Changes to the journal may themselves be journaled for additional redundancy, or the journal may be distributed across multiple physical volumes to protect against device failure.

The internal format of the journal must guard against crashes while the journal itself is being written to. Many journal implementations (such as the JBD2 layer in ext4) bracket every change logged with a checksum, on the understanding that a crash would leave a partially written change with a missing (or mismatched) checksum that can simply be ignored when replaying the journal at next remount.

Physical journals[edit]

A physical journal logs an advance copy of every block that will later be written to the main file system. If there is a crash when the main file system is being written to, the write can simply be replayed to completion when the file system is next mounted. If there is a crash when the write is being logged to the journal, the partial write will have a missing or mismatched checksum and can be ignored at next mount.

Physical journals impose a significant performance penalty because every changed block must be committed twice to storage, but may be acceptable when absolute fault protection is required.^[6]

Logical journals[edit]

A logical journal stores only changes to file metadata in the journal, and trades fault tolerance for substantially better write performance.^[7] A file system with a logical journal still recovers quickly after a crash, but may allow unjournaled file data and journaled metadata to fall out of sync with each other, causing data corruption.

For example, appending to a file may involve three separate writes to:

1. The file's inode, to note in the file's metadata that its size has increased.
2. The free space map, to mark out an allocation of space for the to-be-appended data.
3. The newly allocated space, to actually write the appended data.

In a metadata-only journal, step 3 would not be logged. If step 3 was not done, but steps 1 and 2 are replayed during recovery, the file will be appended with garbage.

Write hazards[edit]

The write cache in most operating systems sorts its writes (using the elevator algorithm or some similar scheme) to maximize throughput. To avoid an out-of-order write hazard with a metadata-only journal, writes for file data must be sorted so that they are committed to storage before their associated metadata. This can be tricky to implement because it requires coordination within the operating system kernel between the file system driver and write cache. An out-of-order write hazard can also occur if a device cannot write blocks immediately to its underlying storage, that is, it cannot flush its write-cache to disk due to deferred write being enabled.

To complicate matters, many mass storage devices have their own write caches, in which they may aggressively reorder writes for better performance. (This is particularly common on magnetic hard drives, which have large seek latencies that can be minimized with elevator sorting.) Some journaling file systems conservatively assume such write-reordering always takes place, and sacrifice performance for correctness by forcing the device to flush its cache at certain points in the journal (called barriers in ext3 and ext4).^[8]

Alternatives[edit]

Soft updates[edit]

Journaled Hard Drive

Some UFS implementations avoid journaling and instead implement soft updates: they order their writes in such a way that the on-disk file system is never inconsistent, or that the only inconsistency that can be created in the event of a crash is a storage leak. To recover from these leaks, the free space map is reconciled against a full walk of the file system at next mount. This garbage collection is usually done in the background.^[9]

Log-structured file systems[edit]

In log-structured file systems, the write-twice penalty does not apply because the journal itself is the file system: it occupies the entire storage device and is structured so that it can be traversed as would a normal file system.

Copy-on-write file systems[edit]

Full copy-on-write file systems (such as ZFS and Btrfs) avoid in-place changes to file data by writing out the data in newly allocated blocks, followed by updated metadata that would point to the new data and disown the old, followed by metadata pointing to that, and so on up to the superblock, or the root of the file system hierarchy. This has the same correctness-preserving properties as a journal, without the write-twice overhead.

What Is A Journaled Hard Drive

See also[edit]

• Journaled File System (JFS) – a file system made by IBM

References[edit]

1. ^ ^abJones, M Tim (June 4, 2008), Anatomy of Linux journaling file systems, IBM DeveloperWorks, archived from the original on February 21, 2009, retrieved April 13, 2009
2. ^ ^abArpaci-Dusseau, Remzi H.; Arpaci-Dusseau, Andrea C. (January 21, 2014), Crash Consistency: FSCK and Journaling(PDF), Arpaci-Dusseau Books, archived(PDF) from the original on January 24, 2014, retrieved January 22, 2014
3. ^'tune2fs(8) – Linux man page'. linux.die.net. Archived from the original on February 25, 2015. Retrieved February 20, 2015.
4. ^''2.4.15-final' - MARC'. marc.info. Retrieved March 24, 2018.
5. ^File Systems from Tanenbaum, A.S. (2008). Modern operating systems (3rd ed., pp. 287). Upper Saddle River, NJ: Prentice Hall.
6. ^Tweedie, Stephen (2000), 'Ext3, journaling filesystem', Proceedings of the Ottawa Linux Symposium: 24–29
7. ^Prabhakaran, Vijayan; Arpaci-Dusseau, Andrea C; Arpaci-Dusseau, Remzi H, 'Analysis and Evolution of Journaling File Systems'(PDF), 2005 USENIX Annual Technical Conference, USENIX Association, archived(PDF) from the original on September 26, 2007, retrieved July 27, 2007.
8. ^Corbet, Jonathan (May 21, 2008), Barriers and journaling filesystems, archived from the original on March 14, 2010, retrieved March 6, 2010
9. ^Seltzer, Margo I; Ganger, Gregory R; McKusick, M Kirk, 'Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems', 2000 USENIX Annual Technical Conference, USENIX Association, archived from the original on October 26, 2007, retrieved July 27, 2007.