Salvaging a “broken” hard drive

Depending on who set up the old Windows machine (ie: if it's from HP, Lenovo, etc) you may have many different partitions on the disk that you normally wouldn't see with Windows. Those partitions might include recovery, unused space, etc. As mentioned in the answer above, use fdisk to see the partitions.

fdisk -l /dev/sdb

Using that information you can find out which partition is where the files you need are located. The largest partition is probably the one you want.

Depending on your distribution and version of Windows, you might need to get the ntfs-4g package in order to mount the disk. It looks like you wanted to mount it readonly and that you expect it to be ntfs3 based on your fstab entry.

mount -o ro /dev/sdbX /media/Microsoft

For the second part of the question you should have several options depending on what you want to do. You can make a normal file systems with mkfs or you could create a logical volume. If you have a modern installation of a recent linux distribution then your system is more than likely using LVM - you can check with the command "vgs". If you receive output with details about a volume group then LVM is in place. You could add the disk to LVM to expand your existing partitions or create a new, independent disk that is mounted somewhere separately.

The exact contents of the journal depend on how you have configured your ext4 file system. The official ext4 documentation says:

There are 3 different data modes:

• writeback mode In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.

• ordered mode In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode.

• journal mode data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all others modes. Enabling this mode will disable delayed allocation and O_DIRECT support.

So you can have both metadata (e.g. file name) and actual data (i.e. file contents) residing in your journal file.

If you're interested in details on the format in which transaction data is actually stored in the journal, you should refer to the respective header file:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/jbd2.h

There's also a wiki page which explains how these structures are laid out on the disk:

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

There's a packet in debian called sleuthkit, in which you have some tools like jls or jcat. The jls tool can list all journal entries of an ext4 file system, for example:

# jls grafi.img

JBlk    Description
0:      Superblock (seq: 0)
sb version: 4
sb version: 4
sb feature_compat flags 0x00000000
sb feature_incompat flags 0x00000000
sb feature_ro_incompat flags 0x00000000
1:      Allocated Descriptor Block (seq: 2)
2:      Allocated FS Block 161
3:      Allocated Commit Block (seq: 2, sec: 1448889478.49360128)
4:      Allocated Descriptor Block (seq: 3)
5:      Allocated FS Block 161
6:      Allocated Commit Block (seq: 3, sec: 1448889494.3355841024)
7:      Allocated Descriptor Block (seq: 4)
8:      Allocated FS Block 145
9:      Allocated FS Block 1
10:     Allocated FS Block 161
11:     Allocated FS Block 129
12:     Allocated FS Block 8359
13:     Allocated FS Block 8353
14:     Allocated FS Block 0
15:     Allocated FS Block 130
16:     Allocated Commit Block (seq: 4, sec: 1448889528.3540304896)
...

And of course, there's more entries depending on the size of the journal. In this case there was about 16382, most of which were empty. If you want to do something with the log, for instance, recover some file, you have to use jcat in order to extract the i-node block:

jcat grafi.img 8 10 > blok-161

And inspect the single i-node. The block is 4096 bytes in size, and covers 16 i-nodes, each of which is 256 bytes long. Anyways in that way you can get the first block of an extent, the number of blocks in the extent, how many extents were used to describe that particular file, its size and other stuff like this. All you need to recover that file from the disk based only on the i-node entry that you got from the journal.

There's also debugfs in e2fsprogs package. It has logdump tool, which is similar to the jls.