Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

350 > FS > Flashcards

FS Flashcards

1
Q

what’s read-modify-write?

A

read in a sector, modify the byte, write it back

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

tradeoff of a sector?

A

+ sector writes are always completed
- larger atomic units have to be created by the OS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

what’s location transparency?

A

the ability to access data w/o knowing its location

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

FS working intuitions

A

FS performance dominated by # of FS accesses
transfer time is negligible compared to seek time + rotational delay

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

tradeoffs of contiguous allocation

A

+ simple, fast access, sequential and random
- external fragmentation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

tradeoffs of linked files

A

+ easy dynamic growth, sequential access, no fragmentation
- non-contiguous blocks = bad access times
- bad random access
- pointers take up space

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

FAT benefits

A

cache entire FAT, cheap compared to disk access when pointer chasing
space overhead trivial
must duplicate to protect against errors

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

indexed files tradeoffs

A

+ sequential, random easy
- mapping table requires large chunk of contiguous space

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

multilevel indexed files

A

+ solves space issues of indexed files
+ small files are fast, large max file size
- worst case 3 FS accesses (di -> i -> b)
- 13 block file = big space overhead
- metadata and data are strewn across disk

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

what are hard links?

A

a refcount of pointers to an inode

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

what are soft links?

A

like a directory: inode has special symlink bit set, file contents are name of target

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

what does the superblock store?

A

block size, # of blocks, max # of files, pointer to head of free list/bitmap, information necessary to locate an inode given its inumber

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

issues with old file system?

A
  • 512B block size too small
  • poor clustering of related objects
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

how FFS fixes block size?

A

4KiB min, increases bandwidth
eliminate internal fragmentation with fragments

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

how FFS fixes clustering?

A

cylinder groups
- data blocks of a file in same CG
- inode and data in same CG
- inodes of a directory in same CG

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

how FFS bitmap improves free list?

A

easier to find contiguous blocks
smaller, keep entire bitmap in RAM

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

tradeoff of the FFS bitmap?

A

time to find a free block increases with fewer free blocks

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

how FFS deals with bitmap tradeoff?

A

trade space, always keep about 10% of disk free, scattered across disk
only root can allocate blocks once 100% full

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

how can FS summary info be wrong?

A

corrupt inodes
fields in inodes are wrong
directories are bad

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

corrupt inodes

A

not a simple crash
- bad block numbers, block used in more than one place

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

fields in inodes wrong

A

count # of directory entries to verify link count, if no entries but count /= 0, move to lost and found
make sure size and used data counts match blocks

22
Q

directories may be bad

A

. and .. must be valid, file names must be unique
all directories must be reachable

23
Q

ordered updates

A

don’t point to garbage
- never write ptr before initializing struct it points to
- never reuse resource before nullifying all ptrs to it
- never clear last ptr to live resource before setting new one

24
Q

block aging

A

block that always has dependency will never get written back

25
Q

soft updates

A

track dependencies, temporarily roll back changes that can’t yet be committed to disk

26
Q

soft update struct for each update field/pointer

A
  • old
  • new
  • list of updates this update depends on
27
Q

dependencies better handled by postponing

A

freeing a block, mark block free in bitmap after the block ptr is cleared on disk

28
Q

operations requiring soft updates

A
  1. block allocation
  2. block deallocation
  3. link addition
  4. link removal
29
Q

block allocation

A

block ptr -> bitmap, data block

30
Q

block deallocation

A

bitmap -> block ptr

31
Q

link addition

A

directory entry -> bitmap, inode

32
Q

link removal

A

bitmap, inode -> directory entry

33
Q

limitations of soft updates

A

very specific to FFS (could not easily apply to XFS)
metadata updates may proceed out of order (e.g. make A, B only B exists after crash)
need slow background fsck to reclaim space

34
Q

limitations of journaling

A

disk write for every metadata operation (soft update create-delete might have no IO)
contention for end of log on multi-processor
fsync must sync other operations’ metadata to log

35
Q

what’s journaling?

A

use write-ahead log
reserve portion of disk for log
write any metadata operation first
after crash, replay log

36
Q

finding oldest relevant log entry?

A

checkpoints
- once all records up to N have been processed and blocks stably committed to disk
- record N to disk in reserved checkpoint location/checkpoint log
- never need to go back before most recent checkpoint

37
Q

allocation group sizes

A

0.5 - 4 GB

38
Q

AGs unlike CGs

A

too large to minimize seek times
no fixed # of inodes per AG

39
Q

advantages of AGs

A

parallelize alloc of blocks/inodes on multiprocessor (have independent locking of different free space structs)
can use 32bit block ptrs within AGs, making data structures smaller

40
Q

B+ trees

A

all kv pairs are in leaves
leaves connected in doubly linked list
all operations logn

41
Q

delayed allocation

A

write syscall only affects buffer cache
assign disk space only when buffers flushed

42
Q

advantages of delayed allocation

A

short-lived files never need disk space allocation
mmapped files often written to RAM in random order, but will be written to disk mostly contiguously
write clustering: find other stuff nearby to write to disk

43
Q

fsync

A

syscall to flush file changes to disk
must also flush dir/parent entries

44
Q

unmount

A

flush all changes to disk on shutdown
some buffers must be flushed multiple times to be clean due to deps

45
Q

unlink

A

syscall returns even if inode/indirect block not cached
deps created faster than blocks written
cap # deps to avoid exhausting memory

46
Q

soft updates fsck

A

split fsck into foreground and background parts

47
Q

foreground fsck

A

must be done before remounting FS
need each CG summary info to make sense
recompute free block/inode counts from bitmaps
leaves FS consistent, might leak space

48
Q

background fsck

A

does traditional fsck operations
after mounting, to recuperate free space
can be using FS while doing this
must be done in foreground after media failure

49
Q

fsck vs soft updates fsck

A

may have many inodes w/ non-zero link counts

50
Q

how are free blocks tracked in XFS?

A

two B+ trees
1. start # -> # free blocks
2. # free blocks -> start #

350 (6 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions