Virtual File System
inode vs file descriptor
422 425
examples-
inode created for pipe put in fd
Contiguous allocation
- block of hard drive allocated to file
- not common, external frag is issue
Linked allocation
- works like linked list
- allocate blocks
- read block, also read pointer to next block
- can't randomly access file (have to trace it )
linked allocation makes optimization difficult (different spots on disk so have to physically move)
indexed allocation
- Linked Scheme
straightforward way, you know where blocks are
- Multi Level Scheme
like multi level page tables
indices of indices
- Combined Scheme **LINUX**
...............................,,,,,.................
worry about concurrency
deadlocks
page cache block
- 4kb blocks
Swap cache block
- good way to avoid race conditions
- try taking away each process's mapping then schedule out harddrive........errrr, what......
- 4kb blocks
Buffer cache
- not like other two @ 4kb chunks , chosen when formated hd
- have to block read requests of user space processes til we know we have the blocks of data that we need
- slower
===================
loop back device
dd copies raw bytes (careful, can screw up your disk)
dd if=/dev/zero of=myhardriveimage.img bs=1024 count=81920
makes 80 meg hardrive image of 1k blocks with input file if and output file of
sudo losetup /dev/loop0 mylhardrive.img
loopback that allows us to pretent fils on other filesystem are devices themselves
journaling filesystem started with ext4 that tracks allocation of space to files
can go through journal if power is yanked, treat as atomic statements
ls /mnt/
sudo mount -t ext3 /dev/loop0 mnt/myfilesystem/
df -Th
(gives info on filesystem)
cd mnt/myfilesystem/
sudo dd if=/dev/urandom mybigfile.bin
(will eventually run out of space)
sudo debugfs /dev/loop0
ls
stat mybigfile.bin
can see inode for mybigfile.bin
inode number
No comments:
Post a Comment