(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2005/0289218A1
`(43) Pub. Date:
`Dec. 29, 2005
`Rothman et al.
`
`US 20050289218A1
`
`(54)
`
`(76)
`
`(21)
`(22)
`
`(51)
`(52)
`
`METHOD TO ENABLE REMOTE STORAGE
`UTILIZATION
`
`(57)
`
`ABSTRACT
`
`Inventors: Michael A. Rothman, Puyallup, WA
`(US); Vincent J. Zimmer, Federal Way,
`WA (US)
`Correspondence Address:
`INTEL/BLAKELY
`12400 WILSHIRE BOULEVARD, SEVENTH
`FLOOR
`LOS ANGELES, CA 90025-1030 (US)
`Appl. No.:
`10/878,470
`
`Filed:
`
`Jun. 28, 2004
`
`Publication Classification
`
`Int. Cl." ............................ G06F 15/16; G06F 12/00
`U.S. Cl. ............................................ 709/203; 711/112
`
`Techniques for enabling remote Storage utilization as local
`disk resources. A virtual disk drive comprising an emulation
`of a non-existent local (to a client) disk drive is facilitated
`via out-of-band (OOB) communications with a remote stor
`age Server in a manner that is transparent to an operating
`System (OS) running on the client. Storage access requests
`are processed in a conventional manner by the client OS,
`being passed as a block Storage request to a firmware driver.
`The firmware driver redirects the request to a remote agent
`running on the remote Storage Server via a LAN microcon
`troller on the client using an OOB channel. A listener at the
`remote Server routes packets to the remote agent. The remote
`agent performs a logical-to-physical Storage block transla
`tion to map the Storage request to appropriate Storage blockS
`on the Server. In one embodiment, an image of the Virtual
`disk is Stored in a single file on the Server. The Scheme
`Supports diskless clients, disk mirroring and remote OS
`provisioning.
`
`
`
`USERAPPLICATIONISSUES STORAGE WRITEACCESS REQUEST
`IDENTIFYINGLOCATION IN VIRTUAL FILETREE AND SIZE
`
`300
`
`OS FILE SYSTEM DETERMINESLOGICALBLOCKADDRESS(ES) (LBA) OF
`BLOCKS) USED TO STORE DATABASED ONSIZE OF FILE AND LOCATION
`NVIRTUAL FILE TREEN VIEW OF WFAT
`
`302
`
`OSDISKDEVICEDRIVERFORMULATES CORRESPONDING
`CONVENTIONAL IDE BLOCK RECUEST TO PASS TO FRMWARELAYER
`
`304
`
`VIRTUAL DISKDEVICEDRIVER PROCESSES REQUEST: BAS AND DATA
`ARE PASSED TO DEREDIRECTIONBLOCK
`
`306
`
`DEREDIRECTIONBLOCKGENERATES REMOTESTORAGEACCESS
`REGUESTIDENTIFYINGLBAS AND DATA
`
`SERIALOVERLANBLOCKGENERATES ONE ORMORE PPACKETS
`CORRESPONDING TO THE ACCESS REQUESTPACKETS CONTAINLBAs,
`DATA AND LISTENERPORT NUMBER
`
`310
`
`OOB IP NETWORKING STACK SENDS PACKETS OVER NETWORK;
`REQUEST ROUTED TO TARGET (REMOTESTORAGE SERVER) IDENTIFIED
`BYMACADDRESS AND PADDRESS
`
`312
`
`PACKETS ARE RECEIVED BY SERVER AND PROCESSED BYP
`NETWORKING STACK
`
`REMOTEAGENT LISTENS FORPACKETS ON PREDETERMINED PORT
`NUMBER(S) AND INTERCEPTS PACKETS
`
`REMOTE AGENT EXTRACTSDATA TRANSLATES LBA OFFSET(S) TO
`WRITE DATA INTO SINGLE ("BLOB") IMAGE FILE
`
`314
`
`316
`
`318
`
`OSANDFWSTORAGEDEVICEDRIVERS PROVIDE INPUTS TO STORAGE
`DEVICE TO UPDATE IMAGE FILEATPHYSICAL STORAGE LOCATION
`
`320
`
`Dropbox Exhibit 1008 - Page 1
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 1 of 8
`
`US 2005/0289218A1
`
`-
`
`are mid 4
`
`rer or
`
`rura
`
`u
`
`mi- m m memo - -
`
`-
`
`a
`
`Fl9. I
`
`ma m
`
`102
`
`218
`
`214
`
`DISKDEVICE DRIVER (OS) 1.
`
`216
`
`210
`
`| RAM
`
`118
`
`Er
`
`|-116
`
`W) T
`
`220
`
`LOAD
`
`110
`
`114
`
`NIC
`
`138
`
`112
`
`LAN CONTROLLER
`FIRMWARE
`OOB IP NETWORKING STACK 145-TEATEow
`
`i
`
`P-2
`IP-1
`100
`MAC-2
`MAC-1
`------------------------
`1445
`148
`236
`O -
`
`
`
`CS
`(S
`
`150
`
`low
`–
`----
`-
`
`D
`-
`O-O
`RO
`DISK ARRAY
`
`204
`
`Dropbox Exhibit 1008 - Page 2
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 2 of 8
`
`
`
`
`
`
`
`(;H) \SIG GE) E
`
`SSE HOOV OWW
`
`SSERHOOVí dl
`
`
`
`
`
`
`
`
`
`Dropbox Exhibit 1008 - Page 3
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 3 of 8
`
`US 2005/0289218 A1
`
`USERAPPLICATION ISSUES STORAGE WRITEACCESS REQUEST
`DENTIFYINGLOCATION IN VIRTUAL FILE TREE AND SIZE
`
`Fig. 3a
`OSFILE SYSTEMDETERMINESLOGICALBLOCK ADDRESS(ES) (LBA) OF
`BLOCK(S) USED TO STORE DATABASED ONSIZE OF FILE AND LOCATION
`IN VIRTUAL FILE TREE IN VIEW OF VFAT
`
`300
`
`302
`
`OSDISKDEVICE DRIVER FORMULATES CORRESPONDING
`CONVENTIONAL IDE BLOCK REOUEST TO PASS TO FIRMWARE LAYER
`
`304
`
`VIRTUAL DISKDEVICE DRIVER PROCESSES REQUEST: LBAS AND DATA
`ARE PASSED TO DE REDIRECTION BLOCK
`
`306
`
`IDEREDIRECTION BLOCK GENERATES REMOTESTORAGE ACCESS
`REQUESTIDENTIFYINGLBAS AND DATA
`
`308
`
`SERIAL OVERLANBLOCK GENERATES ONE ORMORE IP PACKETS
`CORRESPONDING TO THE ACCESS REQUESTPACKETS CONTAINLBAs, 1-310
`DATA AND LISTENERPORT NUMBER
`
`
`
`OOBIPNETWORKING STACK SENDS PACKETS OVERNETWORK;
`REQUESTROUTED TO TARGET (REMOTESTORAGE SERVER) IDENTIFIED-312
`BYMAC ADDRESS AND PADDRESS
`
`PACKETS ARE RECEIVED BY SERVER AND PROCESSED BY IP
`NETWORKING STACK
`
`REMOTEAGENT LISTENS FOR PACKETS ON PREDETERMINED PORT
`NUMBER(S) AND INTERCEPTS PACKETS
`
`REMOTEAGENTEXTRACTSDATA, TRANSLATES LBA OFFSET(S) TO
`WRITE DATA INTO SINGLE ("BLOB") IMAGE FILE
`
`314
`
`316
`
`318
`
`OS ANDFW STORAGE DEVICE DRIVERS PROVIDE INPUTS TO STORAGE
`DEVICE TO UPDATE IMAGE FILEAT PHYSICAL STORAGE LOCATION
`
`320
`
`Dropbox Exhibit 1008 - Page 4
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 4 of 8
`
`US 2005/0289218A1
`
`USERAPPLICATION ISSUES STORAGE READ ACCESS REQUEST
`IDENTIFYINGLOCATION OF FILE IN VIRTUAL FILE TREE (AND SIZE)
`
`301
`
`OS FILE SYSTEMDETERMINESLOGICALBLOCK ADDRESS(ES) (LBA) OF
`BLOCK(S) USED TO STORE DATABASED ONLOCATION IN VIRTUAL FILE - 303
`TREE AND SIZE OF FILE (OR SIZE OF PARTIAL FILE)
`
`PERFORM OPERATIONS OF BLOCKS304,306, 308,310,312,314, AND 316
`OF FIGURE 3a
`
`322
`
`REMOTEAGENT EXTRACTS DATA, TRANSLATESLBAS TOMAP TO
`PHYSICAL BLOCKS IN BLOBIMAGE FILE: SUBMIT READ BLOCK REQUEST
`
`324
`
`RETRIEVE DATA FROM REMOTESTORAGE AND
`RETURN TO REMOTEAGENT
`
`326
`
`REMOTEAGENT REQUESTS NETWORKTRANSFER OF DATA TO CLIENT
`DATA IS PACKETIZED VIASERVER OSPNETWORKING STACKAND SENT
`TO CLIENT USING OOB CHANNEL
`
`328
`
`
`
`
`
`OOBIPNETWORKING uSTACK RECEIVESPACKETS OVER NETWORK;
`PACKETS ARE PROCESSED AND DATA IS EXTRACTED AND FORWARDED
`TO VRTUAL DISKDEVICE DRIVER WAIDEREDIRECTION BLOCK
`
`330
`
`DATAS FORWARDED TO OS DISKDEVICE DRIVER AND RETURNED TO
`USERAPPLICATION VIA OS KERNEL
`
`332
`
`Fig. 3b
`
`Dropbox Exhibit 1008 - Page 5
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 5 of 8
`
`US 2005/0289218A1
`
`
`
`5 CE) Local Disk (C.)
`EE
`Dir. A
`EE
`Dir. B
`E. Dir. B
`Sub. A
`Sub. B
`EJ Sub. C
`Sub. D
`S. Sub. E
`File A
`
`4
`252
`Fig. 4
`
`VIRTUAL FILE ALLOCATION TABLE (VFAT) - 404V
`
`----------------
`
`404vry------
`{{VFAT3, u
`22 yIRTUAL DISK
`
`a Clienta.img <
`
`E. Client.b.img a
`
`E. Client.c.img k
`
`404P
`
`E. Client.d.img -
`PHYSICAL
`
`C FAT (PFAT) D \
`agrico
`Client.d.img
`
`ss.
`
`tra s.l.
`
`P.
`
`E. E. As a
`
`all
`
`re.
`
`50015002 5003 5004 5005. 5010
`50115012501350145015.5020
`50215022502350245025 .. 5030
`50315032503350345035. 5040
`50415042504350445045. 5050
`... . . . . . . . .
`
`
`
`-
`
`Client.c.img
`
`
`
`240
`
`PHYSICAL BLOCK ADDRESS = LBA + OFFSET (5000)
`
`
`
`
`
`
`
`Dropbox Exhibit 1008 - Page 6
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 6 of 8
`
`US 2005/0289218A1
`
`510
`
`
`
`a K
`- - - - - -
`-502
`VIRTUAL DISK'?
`
`OS IMAGE
`
`Y
`
`
`
`
`
`REMOTE STORAGE
`SERVER
`
`Fig. 5a
`
`
`
`/ MIRRORED
`A LOCALDRIVE
`
`REMOTE STORAGE
`SERVER
`
`Dropbox Exhibit 1008 - Page 7
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 7 of 8
`
`US 2005/0289218A1
`
`
`
`
`
`
`
`
`
`INSTALL REMOTE AGENT ON REMOTE STORAGE SERVER
`
`600
`
`PROVISION VIRTUAL DISKSPACE ON REMOTESTORAGE
`SERVER: CREATE "EMPTY" FILE HAVING ALLOCATED
`VIRTUAL DISK STORAGE SIZE APPRIZE REMOTEAGENT
`OF FILE LOCATION AND SIZE
`
`602
`
`STORE VIRTUAL DISKCONFIGURATION PARAMETERS ON
`CLIENT ORDHCP SERVER
`
`604
`
`
`
`STORE REMOTESTORAGE ACCESS PARAMETERS (e.g., IP
`ADDRESS, PORTH) ON CLIENT ORDHCP SERVER
`Fig. 6
`
`606
`
`
`
`SYSTEMRESTART
`
`700
`
`LOAD FIRMWARE VIRTUAL DISKDEVICE DRIVER
`
`702
`
`RETRIEVE VIRTUAL DISKCONFIGURATION PARAMETERS
`AND REMOTESTORAGE ACCESS PARAMETERS FROM
`LOCAL STORE OR DHCP SERVER
`
`704
`
`PROVIDE INTERFACE TO OS REFLECTIVE OF LOCAL DISK
`HAVING CONFIGURATION PARAMETERS OF VIRTUAL DISK
`
`OS STORES DISKCONFIGURATION PARAMETERS FOR
`SESSION USAGE
`
`708
`
`Fig. 7
`
`Dropbox Exhibit 1008 - Page 8
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`Patent Application Publication Dec. 29, 2005 Sheet 8 of 8
`
`US 2005/0289218A1
`
`
`
`
`
`INSTALL REMOTEAGENT ON REMOTESTORAGE SERVER us00
`
`PROVISION VIRTUALDRIVE SPACE ON REMOTE STORAGE
`SERVER: CREATE "EMPTY"FILE HAVING ALLOCATED
`VIRTUAL DISK STORAGE SIZE
`
`BLOCK COPY IMAGE OF OPERATING SYSTEM.INTO FIRST
`PORTION OF ALLOCATED FLE
`
`804.
`
`
`
`NO
`
`DONE
`
`806
`
`YES
`
`CONFIGURE CLIENT TO BOOT FROM VIRTUAL DISK
`
`808
`
`Fig. 8
`
`
`
`PCIe I/F
`
`LAN uC
`
`PROCESSOR
`
`Fig. 9
`
`112
`\.
`
`Ron
`CONTROLLER
`NETWORK I/F
`
`910
`
`900
`
`SPI/F
`904
`
`O4
`
`Dropbox Exhibit 1008 - Page 9
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`US 2005/0289218 A1
`
`Dec. 29, 2005
`
`METHOD TO ENABLE REMOTE STORAGE
`UTILIZATION
`
`FIELD OF THE INVENTION
`0001. The field of invention relates generally to computer
`Systems and, more specifically but not exclusively relates to
`techniques for accessing remote Storage devices that appear
`as local resources.
`
`BACKGROUND INFORMATION
`0002. A common component in most computer systems,
`Such as a personal computer (PC), laptop computer, work
`Station, etc., is a disk drive, also referred to as a hard disk,
`a hard drive, fixed disk, or magnetic disk drive. Disk drives
`Store data on a set of platters (the disks) that are coated with
`a magnetic alloy that is Sensitive to electrical fields intro
`duced by read/write heads that are Scanned over the platters
`using a precision head actuator. As a platterS Spin beneath
`the read/write head at a high rate of Speed (e.g., up to 10,000
`revolutions per minute), electrical impulses are sent to the
`read/write head to write data in the form of binary bit
`Streams on the magnetic Surface of the platters. Reading is
`performed in an analogous manner, wherein magnetic field
`changes are detected in the magnetic platter Surface as the
`platterS Spin to read back a binary bit Stream.
`0003. As disk drives get progressively larger in storage
`capacity, the effect of a failed disk increases. Somewhat
`proportionally. For example, a modern disk drive can store
`250 or more gigabytes of data-enough Storage Space for
`literally 10's of thousands of files, which is generally an
`order of magnitude more than the Storage capacity available
`just a few years ago. Furthermore, it used to be fairly
`common to have multiple disk drives for a given PC, due in
`part to the desire of increasing total platform Storage capac
`ity. In most instances, the failure of one of the multiple disks
`was not as bad as a failure to the only disk drive for the
`System. However, due to the massive capacity of today's
`disk drives, there is rarely the need to have multiple disks for
`a personal WorkStation, Such as a PC.
`0004. This leads to a return to the single disk system.
`Although the mean-time between failure (MTBF) advertised
`for modern disk drives is very impressive (e.g., 100,000
`hours or more), the effective failure rate is significantly
`higher. This is primarily due to the way the MTBF values are
`determined. Obviously, the manufacturer wants to present
`data for its latest product, which means testing of that
`product can only be performed for a limited amount of time,
`such as 2000 hours or less (84 days). Thus, if 500 disk drives
`are tested for 2000 hours each, and one failure results
`(representing 0.2%), the MTBF is 100,000 hours. In the
`meantime, a significant percentage of the same drives might
`fail at 20,000 hours, for example. The point is that disk
`drives are prone to failure at much lower cumulative hours
`than indicated by the MTBF values.
`0005. In order to avoid the potential for catastrophic loss
`of data due to a disk failure, Several approaches are used. For
`example, disk data may be backed up to a tape Storage unit.
`Tape Storage is very tedious, typically requiring manage
`ment of multiple tapes, and very Slow. In reality, most tape
`Storage backup plans for individual users are never imple
`mented with enough consistency to provide a really viable
`backup Solution. In contrast, a good information technology
`
`(IT) department may Successfully use tape storage units to
`backup Servers, wherein the backup is typically performed
`on a daily basis.
`0006 Another solution is to back up the data on another
`disk drive, or a network Storage resource. AS Stated above,
`most of today's computer Systems only have a single disk
`drive, which generally means network backup is the only
`reasonable option for Storing large amounts of data.
`Although this is a viable Solution, it still requires user
`discipline to backup data frequently enough to the network
`in order to prevent a Substantial amount of lost data (and thus
`lost work product) due to a local disk failure.
`0007. In many enterprise environments, diskless work
`Stations are becoming more and more common. Under the
`diskless workstation approach, all persistent data (e.g., data
`for documents) is stored on a remote storage resource that is
`accessed via a network. One of the reasons for the popularity
`of this approach is that Software licensing and configuration
`management is much easier to perform, especially for large
`enterprise environments. For instance, rather than hundreds
`or thousands of unique Software configurations for indi
`vidual WorkStations, only a few configurations need to be
`managed. Furthermore, the IT department can ensure that
`individuals don’t have pirated copies or unlicensed copies of
`applications. In addition, management of Security attacks,
`including protection against Viruses, is more easily handled
`when only a few Servers need to be protected, rather than
`100's or thousands of individual WorkStations. Diskless
`WorkStations also lower capital and maintenance costs.
`0008 Although diskless workstations have their advan
`tages, this Storage approach also presents Several drawbackS.
`Notably, there is no storage if the network is down or unable
`to be accessed from a current location. In addition, network
`disruptions may cause edits to currently-opened documents
`to be lost.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0009. The foregoing aspects and many of the attendant
`advantages of this invention will become more readily
`appreciated as the same becomes better understood by
`reference to the following detailed description, when taken
`in conjunction with the accompanying drawings, wherein
`like reference numerals refer to like parts throughout the
`various views unless otherwise Specified:
`0010 FIG. 1 is a schematic diagram of a computer
`architecture employed at a client to facilitate emulation of a
`non-existent local disk drive as a virtual disk having data
`Stored on a remote Storage Server, according to one embodi
`ment of the invention;
`0011 FIG. 2 is a schematic diagram of a software and
`firmware architecture to Support Virtual disk remote Storage
`operations using the client computer architecture of FIG. 1,
`according to one embodiment of the invention;
`0012 FIG. 3a is a flowchart illustrating operations per
`formed during a remote Storage write proceSS under the
`computer and Software/firmware architectures of FIGS. 1
`and 2, according to one embodiment of the invention;
`0013 FIG. 3b is a flowchart illustrating operations per
`formed during a remote Storage read process under the
`
`Dropbox Exhibit 1008 - Page 10
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`US 2005/0289218 A1
`
`Dec. 29, 2005
`
`computer and Software/firmware architectures of FIGS. 1
`and 2, according to one embodiment of the invention;
`0.014
`FIG. 4 is a schematic diagram illustrating a logi
`cal-to-physical Storage block translation, according to one
`embodiment of the invention;
`0.015
`FIG. 5a is a schematic diagram illustrating an
`implementation of the Virtual disk Scheme for operating
`System provisioning;
`0016 FIG. 5b is a schematic diagram illustrating an
`implementation of the Virtual disk Scheme for mirroring a
`local disk drive;
`0017 FIG. 6 is a flowchart illustrating operations per
`formed in connection with installing the Software and firm
`ware components of FIG. 2;
`0018 FIG. 7 is a flowchart illustrating initialization
`operations that are performed in response to a System restart
`to initialize the firmware and Software components on a
`client;
`FIG. 8 is a flowchart illustrating operations and
`0.019
`logic performed in connection with remote provisioning an
`operating System for a client; according to one embodiment
`of the invention; and
`0020 FIG. 9 is a schematic block diagram illustrating
`components of a LAN microcontroller used in the architec
`tures of FIGS. 1 and 2, according to one embodiment of the
`invention.
`
`DETAILED DESCRIPTION
`Embodiments of methods and apparatus for
`0021
`enabling remote Storage utilization in a manner that is
`transparent to the local WorkStation are described herein. In
`the following description, numerous Specific details are Set
`forth to provide a thorough understanding of embodiments
`of the invention. One skilled in the relevant art will recog
`nize, however, that the invention can be practiced without
`one or more of the Specific details, or with other methods,
`components, materials, etc. In other instances, well-known
`Structures, materials, or operations are not shown or
`described in detail to avoid obscuring aspects of the inven
`tion.
`0022 Reference throughout this specification to “one
`embodiment” or “an embodiment” means that a particular
`feature, Structure, or characteristic described in connection
`with the embodiment is included in at least one embodiment
`of the present invention. Thus, the appearances of the
`phrases “in one embodiment” or “in an embodiment” in
`various places throughout this Specification are not neces
`Sarily all referring to the same embodiment. Furthermore,
`the particular features, Structures, or characteristics may be
`combined in any Suitable manner in one or more embodi
`mentS.
`0023 FIG. 1 shows a system architecture 100 that may
`be used to implement client-side aspects of the remote
`Storage utilization embodiments discussed herein. The archi
`tecture includes various integrated circuit components
`mounted on motherboard or main system board 101. The
`illustrated components include a processor 102, a memory
`controller hub (MCH) 104, random access memory (RAM)
`106, an input/output (I/O) controller hub (ICH) 108, a
`
`non-volatile (NV) store 110, a local area network (LAN)
`microcontroller (uC) 112, a serial flash chip 113, and a
`network interface controller 114. Processor 102 is coupled to
`MCH 104 via a bus 116, while MCH 104 is coupled to RAM
`106 via a memory bus 118 and to ICH 108 via an I/O bus
`120.
`0024. In the illustrated embodiment, ICH 108 is coupled
`to LAN microcontroller 112 via a peripheral component
`interconnect (PCI) Express (PCIe) serial interconnect 122
`and to NIC 114 via a PCI bus 124. Furthermore, various
`devices (not shown) in addition to NIC 114 may be con
`nected to PCI bus 124, Such as one or more PCI add-on
`peripheral cards, including Sound cards, and Video cards, for
`example. The ICH may is also be connected to various I/O
`devices via corresponding interfaces and/or ports. These
`include a universal serial bus (USB) port 126, and a low pin
`count (LPC) bus 128. In one embodiment, firmware store
`110 is connected to ICH 120 via LPC bus 128.
`0025. In the illustrated embodiment, ICH 108 further
`includes an embedded integrated drive electronics (IDE)
`controller 130, which, in turn, is used to control one or more
`IDE disk drives 132 that are connected to the controller via
`an IDE interface 134. IDE controllers and IDE disk drives
`are the most common type of disk drive and controller found
`in modern PCs and laptop computers. Generally, in addition
`to the configuration shown, a separate (from ICH 108) IDE
`controller may be provided for controlling an IDE disk
`drive.
`0026 LAN microcontroller 112 is configured to perform
`various operations that are facilitated via corresponding
`functional blocks. These include an IDE redirection block
`136, a serial over LAN block 138, and an out-of-band
`(OOB) Internet Protocol (IP) networking microstack 140.
`The OOB IP networking microstack 140 supports IP net
`working operations that enable external devices to commu
`nicate with LAN micro-controller 112 via a conventional
`Ethernet connection. Accordingly, LAN micro-controller
`112 also provides a LAN uC Ethernet port 142. Meanwhile,
`NIC 114 also provides a separate NIC Ethernet port 144.
`0027. To effectuate the operation of its various functional
`blocks, LAN microcontroller 112 loads firmware 145 from
`serial flash chip 113 and executes the firmware instructions
`on its built-in processor. (Details of the LAN microcontrol
`ler hardware architecture are shown in FIG. 9 and discussed
`below). In one embodiment, the transfer of data from serial
`flash chip 113 to LAN microcontroller 112 is facilitated by
`a Serial Peripheral Interface (SPI) 146.
`0028. To facilitate concurrent and separate usage, each of
`NIC Ethernet port 144 and LAN uC Ethernet port 142 have
`respective media access control (MAC) addresses and
`respective IP addresses. For simplicity, the respective MAC
`addresses are depicted as MAC-1 and MAC-2, while the
`respective IP addresses are depicted as IP-1 and IP-2. In
`general, NIC Ethernet port 144 and LAN uC Ethernet port
`142 support respective links 147 and 148 to network 150
`using conventional LAN operations and protocols.
`0029. One embodiment of a software/firmware architec
`ture 200 used to implement software and firmware aspects of
`specific implementations described below is shown in FIG.
`2. Architecture 200 includes various Software and firmware
`(FW) components running on a representative client 200
`
`Dropbox Exhibit 1008 - Page 11
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`US 2005/0289218 A1
`
`Dec. 29, 2005
`
`(Also referred to as “Client D,” and a remote storage server
`204. The client and the server are linked in communication
`via network 150 using respective Ethernet links 148 and
`206. The Ethernet link on the server side is facilitated by a
`NIC 207.
`0030 The client-side Software components include a
`client operation system (OS) 208, which is loaded into RAM
`106 and executed on processor 102 of client 202. The OS is
`generally used to run various user applications that are used
`by a user to generate corresponding documents for which
`Storage is required. The illustrated operating System includes
`an OS kernel 210 and an OS user space 212. As will be
`recognized by those skilled in computer arts, the OS kernel
`contains the core operating System components and Services,
`which are typically located into a protected portion of
`System memory. Among these core OS components is an OS
`file system 214 and various device drivers, including a OS
`disk device driver 216.
`0.031
`Under typical operating systems, such as Microsoft
`Windows operating systems, Linux variants, and UNIX
`variants, user applications 218 are run in user Space 212,
`which is a separate memory Space for the memory Space
`reserved for the OS kernel. One reason for using Separate
`memory Spaces is that a corrupted user application will
`usually corrupt a portion of the OS user Space, and not
`corrupt the underlying OS kernel.
`0.032
`Generally, two related components that operate
`together are used to access hardware devices, Such as disk
`drives. These related components are embodied as device
`drivers, with one device driver residing in the OS kernel,
`while the other device driver is a firmware component. One
`reason for this is the lower-level firmware device driver
`provides a layer of abstraction that provides a consistent
`abstracted interface acroSS different types of the Same class
`of devices (in this instance, disk drives).
`0033) One of the interfaces supported by firmware device
`driverS is a block Storage device. A block Storage device
`interface Supports data Storage using logical blocks of Stor
`age. The logical blocks are mapped to an underlying physi
`cal Storage Scheme, Such as that employed for disk drives.
`For example, the Smallest physical unit of Storage for a disk
`drive is a Sector. In Some instances, a number of Sectors are
`combined into clusters, which represent the Smallest addres
`Sable unit of Storage. At the same time, the firmware disk
`drive device driver presents the Storage for the entire disk
`drive as an array of blocks that can be addressed using
`logical block addresses (LBAS). Meanwhile, each LBA is
`mapped by the firmware device driver to the underlying
`physical Storage unit (e.g., a disk Sector). Thus, an OS disk
`device driver can merely specify a storage block or range of
`blocks to be accessed via corresponding LBAS, without
`requiring the OS-level driver to perform any of the under
`lying block translations, or even know Such translations are
`being performed.
`0034.
`In the illustrated embodiment, the aforementioned
`firmware-level disk device driver operations are handled by
`a firmware virtual disk device driver 220. The firmware
`virtual disk device driver presents an interface to OS disk
`device driver 216 corresponding to a local logical block
`Storage device. However, depending on the System configu
`ration (as described below in further detail), there may or not
`be an actual local block Storage device. Rather, a non
`
`existent local block Storage device comprising a virtual disk
`222 is emulated to exist via operations performed, in part, by
`virtual disk device driver 220.
`0035 Virtual disk 222 operations are facilitated via a
`coordinated effort involving Several components. The client
`side components include virtual disk device driver 220, IDE
`redirection block 136, serial over LAN block 138, and OOB
`IP networking microstack 148. Meanwhile, a server-side
`component comprising a remote agent 224 is employed to
`perform Server-Side virtual disk operations.
`0036) Server-side components are depicted on the right
`hand side of Software/firmware architecture 200. The illus
`trated components include a server operating System 224
`including an OS kernel 226. In general, Server operating
`System 224 and client operating System 208 may comprise
`members of the same family of operating System, or may
`not. For example, in one embodiment, client OS 208 com
`prises a MicroSoft Windows operating System, Such as
`Windows XP, 2000, ME, 98, etc., while server operating
`system 224 comprises Windows Server 2000, 2003, or
`Windows NT. In another embodiment, the client runs a
`Windows family OS, while the server OS comprises a
`Linux-variant or a UNIX-variant. In yet another embodi
`ment, the Server OS comprises an operating System specific
`to a large Storage System, Such as a network attached Storage
`(NAS) appliance. For illustrative purposes, the server oper
`ating System components depicted in the embodiment of
`FIG. 2 are illustrative of a Windows Server OS.
`0037 Accordingly, these server OS components include
`an IP networking stack 228, an OS file system 230, and an
`OS storage device driver 232. Meanwhile, the firmware
`level components include a firmware Storage device driver
`234, which provides an abstracted interface between the
`server's OS-level storage device driver and the underlying
`physical Storage device. In the illustrated embodiment, this
`physical Storage device comprises a disk array 236 including
`multiple disk drives 238. The collective storage capacity of
`disk array 236 is depicted to server OS 224 as storage 240.
`Storage 240 may be generally presented as one Storage
`Volume, or multiple Storage Volumes. In one embodiment,
`disk array 236 is implemented as a RAID (redundant array
`of independent (or inexpensive) disks), wherein there is no
`direct mapping between a storage Volume and the underly
`ing disk drives 238.
`0038. In addition to the conventional server-side software
`and firmware components discussed, the Server hosts a
`remote agent 242. Remote agent 242 is used to “intercept
`certain Storage access requests and dynamically generate
`appropriate Storage access commands to access Selected
`portions of Storage 240. In general, remote agent 242 may be
`embodied as an OS kernel component (as shown), or an
`application running in the user space of Server OS 224 (not
`shown). Under one embodiment of a Windows Server
`implementation, remote agent 242 is implemented as a
`Windows service. Under one embodiment of a Linux or
`UNIX implementation, remote agent 242 is implemented as
`a Linux or UNIX daemon.
`0039. In one aspect of the following embodiments, the
`combination of virtual disk device driver 220, IDE redirec
`tion block 136, serial over LAN block 138, OOB IP net
`working microstack 140 and remote agent 242 (in combi
`nation with selected conventional OS and firmware
`
`Dropbox Exhibit 1008 - Page 12
`Dropbox, Inc. v. Entangled Media, LLC
`IPR2024-00285 - U.S. Patent No. 8,484,260
`
`

`

`US 2005/0289218 A1
`
`Dec. 29, 2005
`
`components) Support implementation of a virtual storage
`Space comprising virtual disk 222. The virtual disk appears
`to client operating system 208 (and thus to all of user
`applications 212) as a local disk drive. However, Such a local
`disk drive does not physically exist. Rather, the data “stored”
`on the virtual disk are physically Stored on remote Storage
`240.
`0040 Under the virtual disk scheme, the virtual disk
`effectively operates in the Same manner as a conventional
`local disk drive from the viewpoint of client OS 208. This is
`illustrated by way of example via the operations shown in
`the flowchart of FIGS. 3a and 3b, which correspond to a
`Virtual disk write and read accesses, respectively.
`0041) With reference to FIG. 3a, the virtual disk write
`access process begins in a block 300, wherein a user
`application issues a storage write request identifying a
`location of a file in the virtual file tree, along with the size
`of the file. In cases where the Storage access is to write a new
`file to the virtual disk, the new file will be added to the
`virtual file tree with the file name and location specified via
`the user application. A depiction of an exemplary virtual file
`tree 252 is shown in FIG. 2. For this example, it will be
`considered that a new "File B' is to be added to the virtual
`file tree under Subdirectory “E.” Thus, the location of the
`new file would be specified from the tree root (in this case
`“Local Disk (C:)” to the Subdirectory and new file name,
`C.S.,
`
`Local Disk (C:)/directory C/sub-directory
`0.042
`E/File B.
`0043. The user application's request is passed to the
`operating System and processed by OS file System 214. AS
`depicted in a block 302, the OS file system determines the
`logical block address(es) (LBAs) of the blocks that are used
`to Store the databased on the size of the file and location in
`the virtual file tree. Under a conventional Windows file
`system, a file allocation table (FAT) is used to map the
`location of files within the file tree hierarchy to the physical
`location on actual Storage device. For each file entry in the
`FAT, there is a corresponding entry to the location (e.g.,
`LBA) of the first block in which all or a first portion of the
`file is stored. Since Windows file systems support file
`fragmentation, the location of Subsequent blocks are pro
`vided via a linked list mechanism. As described below, the
`FAT for the virtual disk is referred to as the virtual FAT or
`VFAT.
`0044) The information generated in block 302 is passed
`to OS disk device driver 216 in a block 304. The OS disk
`device driver formulates a corresponding conventional IDE
`block request and passes the request to the firmware layer.
`This conventional IDE block request will be identica