pptx by jianglifang

VIEWS: 0 PAGES: 69

									      ESE250:
Digital Audio Basics


Week 10:  March 26, 2013
      File System




                           1
                 Review
• Everything reduces to bits
  – Songs  digitized and encoded
  – Machine code  bit encoding for machine 
    instructions
  – Ebook text, Homework PDF, movies, …
• Memories store bits
  – Non-volatile memories store them 
    persistently (when the power goes off)

                                               2
Persistent Storage Questions
• How do we save data across boots 
  – When the computer is off
• How do we save data to move between 
  machines?
• How do we organize our data so we can 
  find it again?
  – Tell others to find it?

                                           3
               Strawman #1
• Guess a random address and write data there
• Write down addresses on paper
• To playback song 
  – Run program located at address 42000
  – On data located at address 81736
• How do I know if I can use the block at 
  address 90,000?
• Why might this be problematic?
                                                4
Course Map   Today: file 
             system




                            5
                   Outline
•   What does technology give us?
•   Requirements?
•   Interlude
•   File System Sketch




                                    6
Technology




             7
               Hard Disk
• Disc with magnetic 
  material on its 
  surface




                           8
                   Hard Disk
• Disc with magnetic 
  material on its surface
• Divided into tracks 
  (circles)
• Modern disks 
  – 300,000 TPI
  – TPI = Tracks Per Inch




                               9
                    Hard Disk
• Disc with magnetic 
  material on its surface
• Divided into bit 
  regions 
• Modern disks
  – 1.5M BPI
  – BPI= bits per inch




                                10
                Hard Disk
• Each bit located at a 
  position (R,)
• R = select track
•  = select bit from 
  track
• Disc spins
  – Traces through 



                            11
                Hard Disk
• Each bit located at a 
  position (R,)
• Add arm to move 
  head




                            12
                   Hard Disk
• Each bit located at a 
  position (R,)
• Head arm moves
  – Varies R




                               13
                    Disk Bandwidth
• Typical Disk speed?
  – 15,000 RPM
  – One rotation every 
     • 60s/15,000=4ms
• At R=1 inch and 1.5M BPI, 
  How many bits/second?
  – 2 p  1 in  1.5MB/in / 4ms
  – 9Mbits/4ms = 2.25Gb/s
     • ≈ 280 MB/s


                                     14
            Disk Access Time
• Move head in R?
   – Also a few 
     milliseconds
• Typical Data 
  access: ~10ms
  – E.g. 4ms rotate 
    +6ms seek


                               15
 Throughput and Implications
• Disk throughput and access time
  – 10ms latency
  – 280MB/s throughput (~1B/4ns)
• Observations?
  – Throughput faster than access time
  – 10ms seek  Random byte access 100B/s
  – Sequential access 280MB/s 
  – Want to exploit sequential access!
    • Read blocks of data                   16
          Read Data Blocks
• How many sequential Bytes can read in 
  1ms?
  § 280MB/s  0.001 s 
  § = 280KB
§ Can read 280KB in the same time as 1Byte
  § 6ms seek, 4ms rotation, 1ms data read



                                             17
           Seagate 2.5” Disk Drive




                                                                5400 RPM




http://www.seagate.com/docs/pdf/datasheet/disc/ds_momentus_5400_psd.pdf
                                                                          18
       FLASH Memory (week 8)
• Exploit tunneling
• Use high-voltage to reduce barrier
  – Tunnel charge onto floating node
  – Charge trapped on node    http://commons.wikimedia.org/wiki/File:Flash-Programming.png


• Use field from floating 
  node to modulate 
  conduction




                                                                                             19
w0                                                   bitline
           bitline
                                                   bselect
w1

w2                          Flash                        w0

                                                         w1
w3
                                                         w2

     • NOR -- Read like other memories                   w3

     • NAND – Sequential read within “page”
                                                   gndselect
       – Denser than NOR 
     • Can only “erase” in blocks
       – 4KB, 64KB256KB
     • Once erased can write byte (page) at a time
       – Write time variable
       – Typically need feedback to sense when written
                                                               20
    Samsung 256Mx8 NAND Flash




http://www.datasheetcatalog.com/datasheets_pdf/K/9/E/2/K9E2G08U0M.shtml
                                                                          21
       Intel Solid-State Drive (SSD)




                    35,000/s x 4KB = 140MB/s




SSDhttp://download.intel.com/design/flash/nand/extreme/extreme-sata-ssd-datasheet.pdf

                                                                                        22
Requirements




               23
                    File
• File – sequence of bits that go together
  – MP3 encoding
  – Executable for mp3player
  – Picture in JPEG
  – PDF for your lab write-up
• How big is a file?


                                             24
                      File
• File – sequence of bits that go together
  – Like an object
     • A base address
     • Length or extent
     • Generally has a type…but only used weakly
        – Mp3, WAV, x86 executable, …
  – On Unix/Linux
     • an array of unsigned char
     • with a length 
     • Magic number  tries to convey type
        – Inband, in the file (first word?)
                                                   25
           Create a File?
• What do I need to do to create/store a 
  new file?
  – Allocate/reserve space for it
  – Give it a name?
  – Make a record somewhere of mapping 
    between name and location




                                            26
            Strawman #2               free_address



• Keep track of next free address 
  – free_address – initialized to 0




                                                     27
            Strawman #2
                                      free_address
• Keep track of next free address 
  – free_address – initialized to 0
• When create file, give it space at 
  free_address
  – Increment free_address by length




                                                     28
            Strawman #2
                                      free_address
• Keep track of next free address 
  – free_address – initialized to 0
• When create file, give it space at 
  free_address
  – Increment free_address by length
• Store name & address in table
  – Maybe put table at high addresses

                                                     File1: 0

                                                                29
            Strawman #2
• Keep track of next free address 
                                      free_address
  – free_address – initialized to 0
• When create file, give it space at 
  free_address
  – Increment free_address by length
• Store name & address in table
  – Maybe put table at high addresses

                                                     File1: 0
                                                     File2: 250
                                                              30
            Strawman #2
• Keep track of next free address 
                                      free_address
  – free_address – initialized to 0
• When create file, give it space at 
  free_address
  – Increment free_address by length
• Store name & address in table
  – Maybe put table at high addresses
• When free_address+len>=table_base
  – Device is full                                   File1: 0
                                                     File2: 250
                                                              31
            Strawman #2
• Keep track of next free address 
  – free_address – initialized to 0
• When create file, give it space at 
  free_address
  – Increment free_address by length
• Store name & address in table
  – Maybe put table at high addresses
                                    free_address
• When free_address+len>=table_base                File1: 0
                                                   File2: 250
  – Device is full                                 File3: 350
                                                   File4: 900
                                                   File5: 1100
                                                             32
    Evaluating Strawman #2
                             • Bad
• Good                         – What happens when 
  + Accommodates variable        delete a file?
    length files                     • How reuse space?
  + Allows contiguous          – Add data to files?
    access                     – Table gets big
                               – All filenames have to be 
                                 unique?
                                     • Demands coordination 
                                       between 
                                         – users?
                                         – Programs?
                                         – Programs from 
                                           different vendors?
                                                                33
     Files Grow and Shrink
• Essay/homework gets longer as write it 
  – Don’t know how long it will be when start
• Database of checks written grows
• TODO before end-of-term list shrinks?
• Where put additional space?
  – Allocate new space at end of disk?



                                                34
             Delete Files
• Don’t need lame .o files once build 
  executable
• Replace false start
• That was a bad picture of me
  – Now have better
• Don’t want anyone to see my secret 
  plans to take over the world
• …want the space back because drive 
  filling up
                                         35
        Repurposing Space
• How reclaim space?
• With single free_address pointer
  – can’t keep track of all the places where 
    there is space
• What can do?
  – Keep a list of free regions
  – Try to find a region where will fit


                                                36
   Finding Contiguous Space
• What if our disk looks like this



• …and we want to allocate a large file?
• Disk has capacity
  – But cannot allocate because not 
    contiguous

                                           37
                Bad Sectors
• Portions of a disk head may be bad
  – At manufacture time
  – Go bad during use
• Portions of Flash RAM may be bad
  – Manufacturing defects
  – Limited number of write cycles
• Also inhibits contiguous allocation

                                        38
            Naming Conflicts
                                           /home
• How solve naming conflicts?                 /andre
                                                 /lab9
  – Provide separate contexts                       /solutions.pdf
                                                 /lab10
     • E.g. separate space of names 
                                                    /solutions.pdf
        – for each user                       /bgojman
        – for each program                       /lab9
                                                    /solutions.pdf
  – Typically with a directory structure         /lab10
                                                     /solutions.pdf




                                                                39
                Directory                 File1: 0
                                          File2: 250
                                          File3: 350
                                          File4: 900
                                          File5: 1100
• Special file that contains name to 
  location mappings
• We can easily allow hierarchy 
  – Directories can contain directories




                                                        40
           Requirement Roundup
• Find things easily and quickly
    – Minimize what we need to look at to find data
• Portable (is the sole state holder)
    – Self describing                           Challenge:
•   Fast read                                     both asymptotics
     – Attempt to layout contiguous files         and constants
•   Fast write                                      (e.g. 280MB/s
     – Not take too long to find space for file            vs. 10ms 
•   Support deletion (repurpose capacity)                   random access)
•   Use (most) of capacity                        matter.
    – Allow files to be non-contiguous
• Tolerate errors in media
    – Don’t depend on contiguous blocks to be good
• Isolate/differentiate who can access what
                                                                        41
Interlude




            42
• Jurassic Park Unix-navigation-sequence
• From: “you can’t hold it by yourself” 
  – (around 1:52 into movie)
• To: “…security systems; you name it we got it.”
  – (around 1:54) – less than 2 minute total
  – YouTube clip that is a bit shorter: 
    http://www.youtube.com/watch?v=dFUlAQZB9Ng
  – One that is a bit longer (superset of intent): 
    https://www.youtube.com/watch?v=URVS4H7vrdU




                                                      43
        Disk Data Security
• How is security enforced?
  – OS demands credentials for login
  – User doesn’t get direct access to hardware
  – OS intermediates




                                                 44
      Physical Disk Access
• What happens if the disk is removed 
  from the physical machine?
  – Plugged into another machine that
    • Someone else has administrator access on?
    • Doesn’t respect the users/isolation?




                                                  45
                   Common News Item
Computer hard drive sold on eBay 'had details of
  top secret U.S. missile defence system'
•   By Daily Mail Reporter
    Last updated at 11:08 AM on    07th May 2009
•
    Highly sensitive details of a US military missile air defence system were found on a second-hand hard drive 
    bought on eBay.
•   The test launch procedures were found on a hard disk for the THAAD (Terminal High Altitude Area 
    Defence) ground to air missile defence system, used to shoot down Scud missiles in Iraq.
•   The disk also contained security policies, blueprints of facilities and personal information on employees 
    including social security numbers, belonging to technology company Lockheed Martin - who designed and 
    built the system.
•
    Read more: http://www.dailymail.co.uk/news/article-1178239/Computer-hard-drive-sold-eBay-details-secret-U-S-missile-defence-
    system.html#ixzz0Wxa60PT9




                                                                                                                                   46
                    …all too common
VA Update on Missing Hard Drive in Birmingham, Ala.
• February 10, 2007 Printable Version 
•   Investigation Yielding Additional Information 
•   WASHINGTON -- The Department of Veterans Affairs (VA) today issued an update on the 
    information potentially contained on a missing government-owned, portable hard drive used 
    by a VA employee at a Department facility in Birmingham, Ala.
•   “Our investigation into this incident continues, but I believe it is important to provide the 
    public additional details as quickly as we can,” said Jim Nicholson, Secretary of Veterans 
    Affairs.  “I am concerned and will remain so until we have notified those potentially affected 
    and get to the bottom of what happened.
•   “VA will continue working around the clock to determine every possible detail we can,” 
    Nicholson said.  
•   VA and VA’s Office of Inspector General have learned that data files the employee was 
    working with may have included sensitive VA-related information on approximately 535,000
    individuals.  The investigation has also determined that information on approximately 1.3
    million non-VA physicians – both living and deceased – could have been stored on
    the missing hard drive.  It is believed though, that most of the physician information is 
    readily available to the public.  Some of the files, however, may contain sensitive 
    information.


                                                                                                      47
                         Still Happening
    •   Law Firm Employee Lost Backup Hard Drive on Train; It
        Contained Med-Mal Patient Data
    •   The Baltimore law firm Baxter, Baker, Sidle, Conn & Jones wanted to keep its 
        computer files safe from fire or flooding, so an employee toted a portable backup 
        hard drive home each night.
    •   But the employee lost the hard drive on the train, the Baltimore Sun reports. The 
        data was password-protected, but it was not encrypted, the newspaper says. 
        The hard drive included Social Security numbers and other information on 161 
        stent patients suing a cardiologist who was a client.




http://www.abajournal.com/news/article/law_firm_employee_lost_backup_hard_drive
_with_med-mal_patient_data_on_train/
                                                                                             48
                                 Caveats
• On standard Unix/Windows setups
    – Without the OS to provide protection,
                      all the data is accessible
          • Sometimes good for recovery
    – On standard Unix/Windows setups
          • rm/del doesn’t make the data go away
              – Also sometimes useful for recovery
    – Even format does not guarantee data overwritten
• See: Remembrance of Data Passed: A Study of Disk Sanitization Practices
    –   IEEE Security and Privacy, v1n1p17—27 (linked from today’s reading)




                                                                              49
File System Sketch




                     50
                Sketch
• Manage the disk at the level of blocks of 
  fixed size (bnodes)
• Format disk for bnodes
• File is a collection of bnodes
• Directory is a kind of file
• Root of system bnode in known location


                                               51
                   bnode
• Fixed-size block of data
• Minimum unit of storage allocation 
• bnodes map to physical addresses
  – E.g. bnode 76  address 764096 = 311296 
     • Or bnode 76  R=1.012in, theta=32.07 degrees
• Address physical resources through 
  bnodes

                                                      52
                  bnode Size
• How big should a bnode be?
  – Needs to be bigger than the block address
  – Problems with small blocks?
     • Longer addresses
     • Can address smaller file size w/ fixed # address bits
  – Problems with large blocks?
     • Minimum allocation increment
     • Internal fragmentation 
  – Typical values 4KB, 1KB, 256B
     • Trending toward larger these days 
         – Intel 4KB SSD, 64KB for some flash
                                                               53
         Files from bnodes
• Use bnodes as file handle
                                            76:   obj, 3172
  – How we address the file
• bnode contains metadata
  – Block type, File type, length
• Small file: all data in single bnode
                      obj, 3172      24 Bytes metadata

         4096 Byte                   3172 Bytes
           bnode                     File contents

                                    900 Bytes unused 54
        Files from bnodes
                          76:   obj, 15,791
                                              77:

• Large file: tree of bnodes                  78:

                                              79:

                                              80:




                                                    55
            Files from bnodes
                               76:   obj, 15,791
                                                   77:

• Large file: tree of bnodes                       78:

  – Multi-level if necessary                       79:

                                                   80:



                                      1024
37253:   mp3, 12MB




                                                         56
          Files from bnodes
                                76:   obj, 15,791     77:
• Large file: tree of bnodes                          78:
  – Multi-level if necessary
                                                      79:

                                                      80:
• Overhead for tree structure?
  – 4KB pages 
     • About 1000-way tree
     • 1000KB tree needs 1001 pages
     • 8KB tree needs 3 pages (50% overhead)
        – In practice inodes avoid this worst-case 

                                                            57
                    EXT2 inode



         (12 of these)   indirect
                          blocks




[Source: http://www.tldp.org/LDP/tlk/fs/filesystem.html]
                                                           58
      File Expansion with bnodes
• Expand file
      – Add bnodes to file

76:                 77:      76:
      obj, 15,791                  obj, 18,357   77:
                    78:
                                                 78:
                    79:
                                                 79:
                    80:
                                                 80:

                                          12374:
                                                       59
                        Directory
• File 
  – With type directory
  – contains name/bnode pairs Directory, 234
• Small                             Lab1, 76
  – Fits in one bnode               Lab2, 98
                                    Lab3, 1034
• Large                             Lab4, 267
  – Tree of bnodes                  Lab5, 2053
     • Just like file               ….


                                                 60
        In-class Directory File 
              Simulation
• You will each get one or more bnodes, 
  containing either a directory, a file, or 
  data.
• Root bnode:




• List of free nodes: 160, 161, 162, 163, …
                                               61
                                                       0
                                                       1
                   Free bnodes                         2
                                                       3
                                                       4
                                                       5
• Keep track of free and usable bnodes                 6
                                                       7
• Grouped by contiguous set of free blocks             8
                                                       9
            Length 1: 1, 14                            10
            Length 2: 3-4, 7-8,                        11
                                                       12
            Length 3: 10-12, 16-18                     13
                                                       14
            Length 4: 20--23                           15
• Allocation – try to find contiguous set of           16
                                                       17
  bnodes to satisfy file need                          18
                                                       19
   – …and try not to breakup large contiguous block    20
     unnecessarily                                     21
                                                       22
• Deletion – try to reassemble free blocks             23
   – E.g. delete 13  make 10—14 length 5 block
                                                            62
                Superblock
• For bootstrapping and file system 
  management
  – Each file system has a master block in a canonical 
    location (first block on device)
  – Describes file-system type
  – Root bnode 
  – Keeps track of free lists …at least the head 
    pointers to (bnodes, blocks)
• Corruption on superblock makes file system 
  unreadable
    Store backup copies on disk
                                                          63
             Format disk
• Identify all non-defective bnodes
  – Defective blocks skipped
   those addresses not assigned to bnodes
• Create free bnode data structure
• Create superblock




                                             64
            Review Sketch
•   Manage the disk at the level of bnodes
•   Format disk for bnodes
•   File is a collection of bnodes
•   Directory is a kind of file
•   Root of system bnode in known location



                                             65
            Requirement Review
•   Find things easily and quickly
     – Minimize what we need to look at to find data
         • Directory structure
•   Portable (is the sole state holder)
     – Self describing  superblock, metadata
•   Fast read
     – Attempt to layout contiguous files
•   Fast write
     – Not take too long to find space for file  efficient tree structure
•   Support deletion (repurpose capacity)
     – Return bnodes to free list
•   Use (most) of capacity
     – Allow files to be non-contiguous  bnodes
•   Tolerate errors in media
     – Don’t depend on contiguous blocks to be good  bnodes
•   Isolate/differentiate who can access what

                                                                             66
              Learn More
• Online reading/pointers
  – Unix File System Tutorial
  – Flash, SSD, Hard drive data sheets
  – Data found on hard drive articles
• Courses
  – CIS121 – efficient data structures
  – CIS380 – operating systems


                                         67
                     Big Ideas
• Persistence/Volatility
• Self-describing
   – Every disk different (at least due to media defects)
   – Only place to save data across boots
• Naming
   – Must have canonical way of referencing data
• Indirection 
   – Build logically contiguous region from non-contiguous 
     physical regions
   – Deal with growing, variable size files and errors in 
     media
                                                              68
                    Admin
• Lab 9 due tomorrow at noon

• Lab 10: Design a file system




                                 69

								
To top