file%system%reliability% - courses.cs.washington.edu · lasttime:%file%system%layout •...
TRANSCRIPT
![Page 1: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/1.jpg)
File System Reliability
![Page 2: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/2.jpg)
Main Points
• Problem posed by machine/disk failures • Transac<on concept • Four approaches to reliability – Careful sequencing of file system opera<ons – Copy-‐on-‐write (WAFL, ZFS) – Journalling (NTFS, linux ext4) – Log structure (flash storage)
![Page 3: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/3.jpg)
Last Time: File System Layout
• Tree structure – Asymmetric: FFS
– Balanced: NTFS • Disk oriented free space alloca<on – Disk block groups
• Files in the same directory near each other
• Metadata near data
– Extents: efficient con<guous alloca<on
• Late binding on file size
![Page 4: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/4.jpg)
File System Reliability
• What can happen if disk loses power or machine soUware crashes? – Some opera<ons in progress may complete – Some opera<ons in progress may be lost – Overwrite of a block may only par<ally complete
• File system wants durability (as a minimum!) – Data previously stored can be retrieved (maybe aUer some recovery step), regardless of failure
![Page 5: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/5.jpg)
Storage Reliability Problem
• Single logical file opera<on can involve updates to mul<ple physical disk blocks – inode, indirect block, data block, bitmap, … – With remapping, single update to physical disk block can require mul<ple (even lower level) updates
• At a physical level, opera<ons complete one at a <me – Want concurrent opera<ons for performance
• How do we guarantee consistency regardless of when crash occurs?
![Page 6: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/6.jpg)
Transac<on Concept
• Transac<on is a group of opera<ons – Atomic: opera<ons appear to happen as a group, or not at all (at logical level) • At physical level, only single disk/flash write is atomic
– Durable: opera<ons that complete stay completed • Future failures do not corrupt previously stored data
– Isola<on: other transac<ons do not see results of earlier transac<ons un<l they are commi]ed
– Consistency: sequen<al memory model
![Page 7: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/7.jpg)
Reliability Approach #1: Careful Ordering
• Sequence opera<ons in a specific order – Careful design to allow sequence to be interrupted safely
• Post-‐crash recovery – Read data structures to see if there were any opera<ons in progress
– Clean up/finish as needed
• Approach taken in FAT, FFS (fsck), and many app-‐level recovery schemes (e.g., Word)
![Page 8: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/8.jpg)
FAT: Append Data to File
• Add data block • Add pointer to data block
• Update file tail to point to new MFT entry
• Update access <me at head of file
!le 9 block 3
!le 9 block 0!le 9 block 1!le 9 block 2!le 12 block 0
!le 12 block 1
!le 9 block 4
0123456789
1011121314151617181920
MFT Data Blocks
![Page 9: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/9.jpg)
FAT: Append Data to File
• Add data block • Add pointer to data block
• Update file tail to point to new MFT entry
• Update access <me at head of file
!le 9 block 3
!le 9 block 0!le 9 block 1!le 9 block 2!le 12 block 0
!le 12 block 1
!le 9 block 4
0123456789
1011121314151617181920
MFT Data Blocks
![Page 10: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/10.jpg)
FAT: Append Data to File
Normal opera<on:
• Add data block • Add pointer to data block
• Update file tail to point to new MFT entry
• Update access <me at head of file
Recovery:
• Scan MFT • If entry is unlinked, delete data block
• If access <me is incorrect, update
![Page 11: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/11.jpg)
FAT: Create New File
Normal opera<on: • Allocate data block • Update MFT entry to point to data block
• Update directory with file name -‐> file number – What if directory spans mul<ple disk blocks?
• Update modify <me for directory
Recovery: • Scan MFT • If any unlinked files (not in any directory), delete
• Scan directories for missing update <mes
![Page 12: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/12.jpg)
FFS: Create a File
Normal opera<on: • Allocate data block • Write data block • Allocate inode • Write inode block • Update bitmap of free
blocks • Update directory with file
name -‐> file number • Update modify <me for
directory
Recovery: • Scan inode table • If any unlinked files (not
in any directory), delete • Compare free block
bitmap against inode trees
• Scan directories for missing update/access <mes
Time propor<onal to size of disk
![Page 13: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/13.jpg)
FFS: Move a File
Normal opera<on: • Remove filename from old directory
• Add filename to new directory
Recovery: • Scan all directories to determine set of live files
• Consider files with valid inodes and not in any directory – New file being created? – File move? – File dele<on?
![Page 14: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/14.jpg)
FFS: Move and Grep
Process A
move file from x to y mv x/file y/
Process B
grep across x and y grep x/* y/*
Will grep always see contents of file?
![Page 15: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/15.jpg)
Applica<on Level
Normal opera<on: • Write name of each open
file to app folder • Write changes to backup
file • Rename backup file to be
file (atomic opera<on provided by file system)
• Delete list in app folder on clean shutdown
Recovery: • On startup, see if any files
were leU open • If so, look for backup file • If so, ask user to compare
versions
![Page 16: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/16.jpg)
Careful Ordering
• Pros – Works with minimal support in the disk drive – Works for most mul<-‐step opera<ons
• Cons – Can require <me-‐consuming recovery aUer a failure
– Difficult to reduce every opera<on to a safely interrup<ble sequence of writes
– Difficult to achieve consistency when mul<ple opera<ons occur concurrently
![Page 17: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/17.jpg)
Copy on Write File Layout
• To update file system, write a new version of the file system cotaining the update – Never update in place – Reuse exis<ng unchanged disk blocks
• Seems expensive! But – Updates can be batched – Almost all disk writes can occur in parallel
![Page 18: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/18.jpg)
Copy on Write/Write Anywhere Indirect Blocks
DataBlocks
Inode Array(in Inode File)
FixedLocation
Anywhere
Root InodeSlots
Inode File’sIndirect Blocks
![Page 19: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/19.jpg)
Copy on Write/Write Anywhere
Indirect Blocks
DataBlocks
Inode Array(in Inode File)
Root InodeSlots
Inode File’sIndirect Blocks
Update LastBlock of File
![Page 20: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/20.jpg)
Copy on Write Batch Update Root
InodeRoot
Inode’sIndirect Blocks
InodeFile
File’sIndirect Blocks
File’sData
Blocks
NewData
Blocks
NewData
Block ofInode
File
NewIndirectNodes
NewIndirect
Nodes ofInode
File
NewRoot
Inode
![Page 21: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/21.jpg)
FFS Update in Place
Update Bitmap
Update Inode
Update Indirect Block
New Data Block
![Page 22: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/22.jpg)
Copy on Write Write Loca<on
Old Bitmap
Old Inode
Old Indirect Block
Update InodeUpdate Indirect Block
Update Bitmap
New Data Block
![Page 23: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/23.jpg)
Copy on Write Garbage Collec<on
• For write efficiency, want con<guous sequences of free blocks – Spread across all block groups – Updates leave dead blocks sca]ered
• For read efficiency, want data read together to be in the same block group – Write anywhere leaves related data sca]ered
=> Background coalescing of live/dead blocks
![Page 24: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/24.jpg)
Copy On Write
• Pros – Correct behavior regardless of failures – Fast recovery (root block array) – High throughput (best if updates are batched)
• Cons – Poten<al for high latency – Small changes require many writes – Garbage collec<on essen<al for performance
![Page 25: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/25.jpg)
Logging File Systems
• Instead of modifying data structures on disk directly, write changes to a journal/log – Inten<on list: set of changes we intend to make – Log/Journal is append-‐only
• Once changes are on log, safe to apply changes to data structures on disk – Recovery can read log to see what changes were intended
• Once changes are copied, safe to remove log
![Page 26: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/26.jpg)
Redo Logging
• Prepare – Write all changes (in transac<on) to log
• Commit – Single disk write to make transac<on durable
• Redo – Copy changes to disk
• Garbage collec<on – Reclaim space in log
![Page 27: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/27.jpg)
Redo Logging
• Recovery – Read log – Redo any opera<ons for commi]ed transac<ons – Garbage collect log
![Page 28: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/28.jpg)
Before Transac<on Start
Log:Storage
Mike = $100Tom = $200
Mike = $100Tom = $200Cache
Nonvolatile
![Page 29: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/29.jpg)
AUer Updates Are Logged
Tom = $100 Mike = $200Storage
Mike = $100Tom = $200
Mike = $200Tom = $100Cache
Log:
Nonvolatile
![Page 30: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/30.jpg)
AUer Commit Logged
Tom = $100 Mike = $200 COMMITStorage
Mike = $100Tom = $200
Mike = $200Tom = $100Cache
Log:
Nonvolatile
![Page 31: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/31.jpg)
AUer Copy Back
Tom = $100 Mike = $200 COMMITStorage
Mike = $200Tom = $100
Mike = $200Tom = $100Cache
Log:
Nonvolatile
![Page 32: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/32.jpg)
AUer Garbage Collec<on
Log:Storage
Mike = $200Tom = $100
Mike = $200Tom = $100Cache
Nonvolatile
![Page 33: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/33.jpg)
Ques<on
• What happens if machine crashes? – Before transac<on start – AUer transac<on start, before opera<ons are logged – AUer opera<ons are logged, before commit – AUer commit, before write back
– AUer write back before garbage collec<on • What happens if machine crashes during recovery? – Write back is idempotent – redo can be redone
![Page 34: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/34.jpg)
Performance
• Log wri]en sequen<ally – OUen kept in flash storage
• Asynchronous write back – Any order as long as all changes are logged before commit, and all write backs occur aUer commit
• Can process mul<ple transac<ons – Transac<on ID in each log entry – Transac<on completed iff its commit record is in log
![Page 35: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/35.jpg)
Volatile Memory
Complete
Mixed:
WB Complete
Committed
Uncommitted
Free Free... ...
older newerAvailable for
New RecordsEligible for GC In UseGarbage Collected
Log!head pointer
Log:
Persistent Storage
Log!head pointer Log!tail pointerPending write!backs
Writeback
![Page 36: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/36.jpg)
Redo Log Implementa<on Volatile Memory
Complete
Mixed:
WB Complete
Committed
Uncommitted
Free Free... ...
older newerAvailable for
New RecordsEligible for GC In UseGarbage Collected
Log!head pointer
Log:
Persistent Storage
Log!head pointer Log!tail pointerPending write!backs
Writeback
![Page 37: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/37.jpg)
Transac<on Isola<on
Process A
move file from x to y mv x/file y/
Process B
grep across x and y grep x/* y/* > log
What if grep starts aUer changes are logged, but before commit?
![Page 38: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/38.jpg)
Two Phase Locking
• Two phase locking: release locks only AFTER transac<on commit – Prevents a process from seeing results of another transac<on that might not commit
![Page 39: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/39.jpg)
Transac<on Isola<on
Process A
Lock x, y move file from x to y
mv x/file y/
Commit and release x,y
Process B
Lock x, y, log grep across x and y
grep x/* y/* > log
Commit and release x, y, log
What if grep starts aUer changes are logged, but before commit?
![Page 40: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/40.jpg)
Caveat
• Most file systems implement a transac<onal model internally – Copy on write – Redo logging
• Most file systems provide a transac<onal model for individual system calls – File rename, move, …
• Most file systems do NOT provide a transac<onal model for user data – Historical ar<fact (imo)
![Page 41: File%System%Reliability% - courses.cs.washington.edu · LastTime:%File%System%Layout • Tree%structure% – Asymmetric:%FFS% – Balanced:%NTFS% • Disk%oriented%free%space%allocaon%](https://reader030.vdocument.in/reader030/viewer/2022041022/5ed2e1fd4768b17a6774256c/html5/thumbnails/41.jpg)
Log Structure
• Can we eliminate the copy back?