8

Filesystem overhead. Every time you create a file, the filesystem reserves space on disk to store the file name, and other metadata like its permissions, creation date, etc. It also has to maintain a sort of index of all the (possibly sparse) blocks occupied by each file. The index might be a simple list or a tree, depending on the filesystem. Finally, ...


8

A B-Tree is a type of dictionary, no more and no less. It can be used to implement a set (e.g. see the interface for java.util.Set for the sort of operations we're talking about), but is most commonly used to implement a map (ditto for java.util.Map). So let's just look at maps for a moment. If you think about a linguistic dictionary, it's ordered by "word",...


7

First, let me state that you may have things to unlearn. Files that are a stream of bytes are very much the rule, and have been for a long time. Almost all filesystems store a sequence of bytes, and leave the interpretation of that sequence of bytes up to applications or at least to higher-level libraries. Sequential files, consisting of a sequence (...


6

According to Wikipedia, a computer file is simply a resource for storing information. The term appears to have originated in the punch card era, where a computer program was literally stored in a file (as in, a box used to store loose pages, see image below). As other forms of media were introduced, such as disks, the nomenclature followed. From a *nix ...


6

The OS references blocks using a "logical block address". The SD card then maps this to a physical page of flash memory. With wear leveling, each time data in that block is changed, it will get mapped to a new physical page of flash memory. So, even though the OS is changing the same "logical block address" every time, this is causing ...


5

For most file systems, a directory lists its entries in a certain order, so reading ("scanning") an individual directory will return its entries in that order. But when it comes to scanning whole directory structures, there is no such thing as "core scanning": there isn't a common implementation for that. I think depth-first is more popular; e.g. GNU find ...


4

First of all, it is not necessarily true that on average half a block is wasted. The main reason why this is false is that for small files it might be the case the more than half a block is wasted on average. Moreover, this is your main worry regarding this wastage, since is you waste half a block per large file, the fraction of blocks wasted is actually ...


4

Yes, every file has an integer amount of bytes. In fact, most file systems deal with blocks or clusters of bytes. If cluster size is 64KB a file may claim to take up 250KB, but it will actually take 4 clusters or 256KB. This reduces the problem of fragmentaton (now fragments can only get so small, and there can only be so many of them) and the problem of ...


3

The "file allocation table" (which gives the FAT filesystem its name) is a fixed-size array "statically allocated at the time of formatting." Its size is determined by the size of the partition, because "The table contains entries for each cluster, a contiguous area of disk storage." (quoted from Wikipedia). So if the partition is made larger, the FAT has ...


3

I think that many programmers would look at it in terms of the conversions between the two formats, and say that each format can be converted to the other losslessly, and that it's possible to make a round-trip without losing any data. It's not a standard usage, but if you said that the two formats were round-trippable wrt each other, you would probably be ...


3

TL;DR: You don't have to worry about seek times with SSDs like you do with hard disks. As a first-order approximation, you can think of them as random-access devices. SSDs let you read and write entire blocks. There is some cost to read/write a particular block (usually under 0.1ms). Once you're reading or writing a block, it's a lot faster to read/write ...


3

Your intuition is mostly correct. I believe the description is not really sufficient. Directory entry should at least be able to allow the OS to be able to locate some parts the file on disk for I/O operations. File System is divided into some fixed size partitions of available space ranging from 1-16KB. For efficient implementations a file is not ...


3

Think of the file system and its files as a big cabinet with lots of physical folders in an office of bureaucrats. The sheets in the folders are arranged in fixed ways such that every bureaucrat knows exactly where to expect which information before taking the folder out of the cabinet. Not let us assume that a bureaucrat (a program) performs a certain ...


3

Singly and doubly linked lists have the identical (terrible) linear access time. Using doubly linked lists would not help performance. The only benefit you'd get is that reading file backwards is more efficient. No modern file system uses linked allocation anymore. Most use ranges of consecutive blocks, so called extents. Extents are usually more space-...


3

When flash storage is exposed directly to the operating system, it's used with a file system specifically designed for flash, like JFFS2. USB and SATA flash drives emulate Winchester hard drives, and do wear leveling in the firmware. The details are proprietary and specific to each drive, but it's probably broadly similar to the way JFFS2 works. A file ...


2

This is not likely to be very effective in practice. Malware might corrupt the file before you were first able to take a snapshot... or, more realistically, it might corrupt the snapshot you have taken, so that the snapshot matches the current version of the file. It is difficult to defend against that attack. So, while your idea is not a bad one, it has ...


2

I've never heard of sequential files, but apparently the term can mean two things: Data which can only be accessed sequentially, for example the contents of a backup tape. Record-based files (what Stallings refers to). Apparently this is still used in databases (see for example this COBOL page), but not on your desktop. File names and other metadata such ...


2

The +1 is for the newline character. The byte count equals the number of characters, in this case, because each character takes exactly one byte. That need not be true in general (see, e.g., UTF-8), but it is for the example you listed. You didn't write an integer to the file. You wrote a string -- a sequence of characters, namely the character 1, then ...


2

It depends on the file system used and preferences provided, but in the most common case - deleted data is marked as deleted (dirty) and is used when some new data is to be written. Priority of usage of dirty block earlier than empty depends on system preferences. The recycle bin is different case - until emptied there is guarantee to recover files, so it ...


2

I propose this, more direct to code (in java, c, etc.) read each line (until CR/LF) at begining, read a number, until spaces => number n after that, take next characters of line split them by , for each, trim (delete space before or after) => strings s1, s2, s3 then output n s1 CRLF n s2 CRLF n s3, etc.


2

I think of a file as a sequence of bytes. Even after it loses its name (usually caused by a call to rm, which unlinks it), it still exists on the disk until its chunks get overwritten by other stuff. File formats are contexts for reading files. It all goes back to the principle that information is bytes plus context. The previous poster is right that ...


2

A directory is a collection of files, some of which could be directories. You can store the list of files forming a directory as a linear list. This is somewhat similar to the adjacency list representation of a graph (imagine that the graph were a tree). Each node in the list contains some sort of information regarding the file, such as the name, size and ...


2

OEM Parameter block The OEM block not only stores data about the filesystem, it also contains information about the physical hard drive geometry, or about how files are laid out on your hard drive or SSD. This was used by older BIOSes to determine how a hard drive was set up from the manufacturer. As a good primer for explaining hard drive geometry, I can ...


2

The MBR refers to the format used by (many but not all, and slowly being replaced by GPT) disk to identity partitions. A partition is simply a contiguous range of blocks on the disk. A partition is often used to store data, in the form of files and directories. But of course a disk knows nothing about files and directories. A file system is a system that ...


2

Just having malicious instructions loaded into memory is not a problem in itself. Instructions (code) is just binary, so it might be stored in the data segment. Where it becomes a problem is if something causes that code to be executed. It's not clear why a video player would jump to data inside an image. If it had a security vulnerability, that could ...


2

It’s just historical. Old file systems are not journaled, and they cannot be resized. At some point in time journaling was added, and at some point in two resizing was added. So new file systems have both features. You obviously don’t need the ability to resize a disk to implement journaling, but there is also no reason why journaling would be needed for ...


1

The correct answer is: greater or equal to K/D, depending on the fact that K can be a multiple of D or not. So, the answer is actually c), which differs from the other three answers. Note that if there were an answer “ceil(K/D)”, that would have been the correct answer.


1

Information like "creation time" is called metadata. The filesystem stores both the contents of the file and its associated metadata on the hard drive. It has to -- if you reboot the computer, we need that information to persist, so it has to be stored somewhere that will survive reboots. That place is the hard drive. See https://en.wikipedia.org/wiki/...


1

Step 3 of that description is indeed a bit confusing, and your comments are right. The short answer is that the OS keeps track, in memory, of the set of mounted file systems and where they are mounted.


1

You usually have several layers. You will have a physical level, where complete sectors can be read or written - except on SSD drives, you can only write into an area that is zeroed, and you can only zero sectors 32 or 64 at a time. Much more interesting than a hard drive. On top of that you have a level that is still in the hard drive. Caches on a hard ...


Only top voted, non community-wiki answers of a minimum length are eligible