WEBVTT

0:00:09.440000 --> 0:00:15.460000
 So let's talk about the FET file system
 and how to analyze this file system.

0:00:15.460000 --> 0:00:21.320000
 The first question to ask is, why is
 it important to learn an out-of-date

0:00:21.320000 --> 0:00:26.340000
 file system that we really
 haven't used in years?

0:00:26.340000 --> 0:00:34.000000
 Or have we? That is relatively
 simple, but it is quite robust.

0:00:34.000000 --> 0:00:39.880000
 While it is definitely no longer used
 beneath the operating systems, it's

0:00:39.880000 --> 0:00:44.340000
 still compatible and supported across
 the board amongst most operating

0:00:44.340000 --> 0:00:49.540000
 systems. And it's commonly used on smaller
 storage devices, and you want

0:00:49.540000 --> 0:00:55.540000
 to think about some embedded systems
 like operational technology or IoT.

0:00:55.540000 --> 0:01:00.320000
 For our purposes, it also has the added
 benefit that it's incredibly easy

0:01:00.320000 --> 0:01:06.100000
 to learn. FET's functionality is a
 little more intuitive, making it a

0:01:06.100000 --> 0:01:10.900000
 great place to start learning about
 and understanding how file systems

0:01:10.900000 --> 0:01:18.440000
 work. Now, FET 32 is the most common variation
 you're going to come across,

0:01:18.440000 --> 0:01:28.940000
 and what that means is to support those
 four quadrillion bytes or around

0:01:28.940000 --> 0:01:33.240000
 two terabytes. And what you need to know
 is that there are some iterations

0:01:33.240000 --> 0:01:38.920000
 that went through FET 12, FET 16, FET
 32, and what you see is the size

0:01:38.920000 --> 0:01:46.120000
 and the amount of disk space and then
 the cluster size slowly increased

0:01:46.120000 --> 0:01:51.640000
 to over time. Now some things to think
 about now, we're going to add something

0:01:51.640000 --> 0:01:54.680000
 new into the equation here,
 it's called a cluster.

0:01:54.680000 --> 0:01:59.400000
 Clusters and sectors
 are very similar.

0:01:59.400000 --> 0:02:03.960000
 And what you need to know is while
 sector sizes are physical segments

0:02:03.960000 --> 0:02:10.900000
 of the hard drive and their size, either
 512 or 4096 bytes, is determined

0:02:10.900000 --> 0:02:13.040000
 by the hardware.

0:02:13.040000 --> 0:02:17.760000
 However, the difference is clusters
 are going to be logical segments and

0:02:17.760000 --> 0:02:22.080000
 their size is determined
 by the file system.

0:02:22.080000 --> 0:02:27.760000
 The software performing the disk format
 will generally recommend a default.

0:02:27.760000 --> 0:02:32.520000
 However, you can change that default,
 but knowing that you're going to

0:02:32.520000 --> 0:02:36.720000
 deviate a little bit from the recommendations
 going to balance performance

0:02:36.720000 --> 0:02:41.460000
 and utilization, it's really a difference
 in, are you going to have a

0:02:41.460000 --> 0:02:42.960000
 whole bunch of small files?

0:02:42.960000 --> 0:02:49.020000
 In that case, you want to utilize a
 small sector size or are you going

0:02:49.020000 --> 0:02:51.340000
 to have like a gigantic
 database, right?

0:02:51.340000 --> 0:02:56.200000
 If you have a gigantic database, then
 you want to use larger cluster sizes

0:02:56.200000 --> 0:03:01.400000
 because when that file is created, the
 file system allocates the number

0:03:01.400000 --> 0:03:03.460000
 of clusters to that file storage.

0:03:03.460000 --> 0:03:08.640000
 So say if you have a really small file
 that will fit into one cluster,

0:03:08.640000 --> 0:03:13.620000
 you're going to fit more files than
 say a really small file that fits

0:03:13.620000 --> 0:03:15.180000
 into two or three clusters.

0:03:15.180000 --> 0:03:19.180000
 It's going to have that extra space
 taken up by that, that cluster is

0:03:19.180000 --> 0:03:24.740000
 going to to reduce the amount of
 disk space available to you.

0:03:24.740000 --> 0:03:32.420000
 Now we did talk about performance because
 we also map clusters in forms

0:03:32.420000 --> 0:03:35.260000
 of contiguous sectors, right?

0:03:35.260000 --> 0:03:41.120000
 A larger cluster size is going to be
 indicative of the potential for a

0:03:41.120000 --> 0:03:49.540000
 less file fragmentation, but it can
 also mean more slack space, right?

0:03:49.540000 --> 0:03:51.420000
 And what is slack space?

0:03:51.420000 --> 0:03:56.360000
 It's simply the amount of space
 in that cluster that's not used.

0:03:56.360000 --> 0:04:00.920000
 For example, the cluster size
 is four kilobytes for fat 12.

0:04:00.920000 --> 0:04:07.600000
 A six kilobyte file will fill one and
 a half clusters leaving half a cluster

0:04:07.600000 --> 0:04:09.660000
 of slack space available.

0:04:09.660000 --> 0:04:15.040000
 And there could be data in that slack
 space that was utilized the previous

0:04:15.040000 --> 0:04:17.540000
 time there was a file
 in that cluster.

0:04:17.540000 --> 0:04:22.840000
 So what this talks about is looking
 high and looking low.

0:04:22.840000 --> 0:04:25.980000
 High level says we're going to
 the logical clusters, okay?

0:04:25.980000 --> 0:04:29.940000
 Whereas low means we're going to look
 at the physical sectors kind of

0:04:29.940000 --> 0:04:33.100000
 following the concept
 of an OSI model.

0:04:33.100000 --> 0:04:36.280000
 And what we're saying is in the previous
 example, we would say that the

0:04:36.280000 --> 0:04:39.360000
 high level view showed
 two clusters allocated.

0:04:39.360000 --> 0:04:45.440000
 However, the low level view said that
 only 12 of the 16 sectors were used

0:04:45.440000 --> 0:04:47.760000
 across the two clusters.

0:04:47.760000 --> 0:04:52.340000
 Let's look at the file
 allocation table.

0:04:52.340000 --> 0:04:57.600000
 Clut system. Fat breaks down the
 partition into three segments.

0:04:57.600000 --> 0:05:03.160000
 Those segments are reserved area,
 fat area, and the data area.

0:05:03.160000 --> 0:05:08.320000
 The reserved area will vary in length
 based on the type of the fat used.

0:05:08.320000 --> 0:05:12.780000
 The fat area holds the file allocation
 tables themselves.

0:05:12.780000 --> 0:05:19.480000
 And in the data area is going to be where
 all of that data actually resides.

0:05:19.480000 --> 0:05:22.880000
 Inside of the reserved area, we're going
 to see the boot sector, the FS

0:05:22.880000 --> 0:05:28.460000
 info area, the bootstrap, and
 then the reserved sectors.

0:05:28.460000 --> 0:05:38.340000
 Inside of the fat area, you're going
 to see fat one and fat two.

0:05:38.340000 --> 0:05:43.580000
 Fat one is primarily where the operating
 system is going to look for the

0:05:43.580000 --> 0:05:50.760000
 file allocations in fat two is going
 to be a backup in case fat one is

0:05:50.760000 --> 0:05:54.360000
 broken. And then after fat two
 is going to be the data area.

0:05:54.360000 --> 0:05:56.840000
 Now I want you to look
 at this diagram.

0:05:56.840000 --> 0:06:02.560000
 Just take a second and look at this diagram
 and see if you can see what's

0:06:02.560000 --> 0:06:12.860000
 wrong with it and what the vulnerability
 is to our file allocation tables.

0:06:12.860000 --> 0:06:18.460000
 If your question that you're asking
 is, if fat two is a backup of fat

0:06:18.460000 --> 0:06:21.740000
 one, why is fat two right
 behind fat one?

0:06:21.740000 --> 0:06:27.700000
 And you're absolutely correct because
 if the data area that fat one is

0:06:27.700000 --> 0:06:33.480000
 residing on is damaged, there's also
 a very high likelihood that fat two

0:06:33.480000 --> 0:06:34.340000
 is also damaged.

0:06:34.340000 --> 0:06:37.640000
 And if both are damaged,
 then we have a problem.

0:06:37.640000 --> 0:06:40.920000
 Okay, so I want you to think about that
 and I want you to watch in some

0:06:40.920000 --> 0:06:46.840000
 other file systems and tell me an answer
 to yourself if you think that

0:06:46.840000 --> 0:06:50.000000
 maybe some other file systems
 have figured this out.

0:06:50.000000 --> 0:06:54.020000
 Okay, now let's talk about the data
 that contains, let's talk about the

0:06:54.020000 --> 0:06:57.720000
 area that actually contains all the
 data stored within the partition.

0:06:57.720000 --> 0:07:00.100000
 That's going to be the files
 and directories alike.

0:07:00.100000 --> 0:07:04.420000
 In fact, this is a good time to mention
 that directories are really just

0:07:04.420000 --> 0:07:09.420000
 a special type of file that contains
 the file names and the metadata of

0:07:09.420000 --> 0:07:12.940000
 the files that appear to
 be stored inside of it.

0:07:12.940000 --> 0:07:16.780000
 At this point, the most important takeaway
 on this is going to be the

0:07:16.780000 --> 0:07:20.760000
 relationship between a file
 system and its data area.

0:07:20.760000 --> 0:07:26.900000
 The file system keeps track of what data's
 and directories exist and what

0:07:26.900000 --> 0:07:28.520000
 clusters they are allocated to.