JP5715964B2 - Managing downloadable files - Google Patents

Description

  The present invention relates generally to storage devices, and more particularly to a method and apparatus for managing files in a storage device.

PRIORITY CLAIM This application is March 10, 2009 to No. filed US Provisional Patent Application No. 61 / 159,034 (Patent Document 1) (pending) and US provisional patent filed on November 9, 2009 The claims of both applications 61 / 259,418 (patent document 2) (pending) are claimed, each of which is incorporated herein by reference in its entirety.

  The use of non-volatile storage devices has been expanding rapidly over the years because they are portable, have a small physical size and a large storage capacity. There are storage devices of various designs. Some storage devices are considered “embedded”, which means that they cannot be removed by a user from a cooperating host device and are not intended to be removed. Other storage devices are removable, but it allows the user to move them from one host device (eg, from a digital camera) to another host device, or one storage device to another storage device Means that it can be replaced.

  The digital content stored in the storage device may originate from the storage device host. For example, a digital camera that is a representative host captures images and converts them into corresponding digital data. The digital camera then stores the digital data in a storage device that cooperates with the digital camera. The digital content stored in the storage device also originates from a remote source, which is sent to the storage device host via, for example, a data network (eg, the Internet) or a communication network (eg, a cellular telephone network). Can then be downloaded to the storage device by the host. The remote source can be, for example, a service provider or a content provider. The service provider and the content provider are hereinafter collectively referred to as “issuer”.

  As the capacity and capacity of storage devices in mobile handsets grows, new scenarios for on-the-go content acquisition and consumption will become available. Typically, handsets can be used to consume movies and music downloaded from operator controlled servers, market applications such as Apple's iTunes service, and sideloaded from sources such as SanDisk Corporation's slotMedia cards. However, in all of these applications, the user proactively searches for the content he wants to consume, presents the acquisition of that content, is authorized, acquires that content, and then consumes it There must be. This reduces the ability of the content owner to provide the content for immediate consumption, as well as the ability for the user to see what he gets without waiting for it to download.

  Although many product concepts have been devised around preloading content to the user, they all have one common drawback, and the user has to save his or her own storage capacity to store the content. You have to sacrifice, but you can't access the content until you purchase it. Users who have to purchase this capacity typically do not want to see a significant portion of what is allocated to content that they cannot actually use.

  A user of the storage device can voluntarily download the media content and advertisement by requesting the media content or advertisement from the publisher. However, sometimes publishers try to increase their income without asking for user permission, and sometimes users do not realize that such content has been downloaded to their storage device. Send to user. The content that the issuer sends to the user without obtaining the user's consent is referred to herein as “unsolicited content”. Often, unsolicited content is intended to be consumed by the user after paying or promising to pay the issuer.

  By downloading unsolicited content to the user's storage device, the issuer wants the user to eventually consume the unsolicited content in exchange for a fee and increase their revenue. The issue of publishers that store unsolicited content in storage without asking for user consent and that the user wants to consume that content in return for a fee is the “predictive consignment” in the media publishing field. ) ". However, unsolicited content may remain stored on the storage device even though the user of the storage device does not know that it exists and does not want to consume it. Storing unsolicited content in the storage device reduces the available (ie, free) user storage space on the storage device, which is undesirable from the user's perspective. There is less space in the storage for the user's own content (eg, music files) because someone else (ie, an issuer) has occupied some of the storage space on the storage device; Alternatively, the user may notice that the storage space so occupied may have to be recovered by deleting unsolicited content.

  One partial solution to the problem of occupying a portion of the user's storage space is to block the publisher's access to the storage device, such as by blocking the publisher's website. While this solution may be satisfactory to the user, it is a problem from the issuer's point of view because the issuer's sales will be reduced and potential revenue sources will be lost. Another partial solution to this problem is to publish content to hosts (i.e. store content files in their host storage) and remove the content when it becomes meaningless. Can be mentioned. In other words, the publisher that brought the content removes the stored unsolicited content from its storage device when the content becomes meaningless. Unsolicited content is considered meaningless if the time for its consumption has elapsed or when there is an indication that the user is unlikely to consume it.

  Therefore, there is a need for a new technology that intelligently manages handset storage so that users can freely use their storage without penalties, while content owners can sell content to the handset. Therefore, in other words, it is necessary to deal with problems associated with unsolicited files. Specifically, publishers should be allowed to carry out unsolicited content downloads to storage devices in the course of their business, but that download is decisive to discourage the user experience. It should not have any influence.

US Provisional Patent Application No. 61 / 159,034 US provisional patent application 61 / 259,418 US patent application Ser. No. 12 / 336,089 US Provisional Patent Application No. 61 / 159,034

  Thus, unsolicited files can be stored in the storage device while the storage space required to accommodate them in the storage device is not required for the user's files, and minimal for user files It would be beneficial to be able to remove unsolicited files from the storage device to guarantee free storage space of size. Various embodiments are designed to perform such file management, examples of which are provided here.

  A file stored or to be stored in a storage device to handle the foregoing is marked as non-disposable or disposable in the structure of the file system associated with the storage device. Each marked file is associated with a discard priority level. A new issuer's file (ie, an unsolicited file) only if the storage usage safety margin reserved for the user file does not narrow beyond the desired margin when it is stored in storage Allowed to be stored in the storage device. On the other hand, storing user files is allowed to be stored in the storage device even if the storage use safety margin is narrowed beyond the desired width. However, in such a case, the desired width of the storage usage safety margin is restored by removing one or more disposable files from the storage device. A discardable file is removed from storage when its discard priority level is equal to or higher than a predetermined discard threshold (or lower, as described herein).

  The download manager is part of the storage allocator in some implementations, both of which reside in the host, storage device, or a combination of both, and the download manager is discarded into the storage area of the storage device. Manage possible downloads based on one or more download conditions. A request to store a file in a storage area of a storage device is received and the file is a discardable file and is associated with data in a data structure associated with the storage device. In some implementations, the data structure can include a file system structure associated with the storage device. The file is marked as a discardable file. In some implementations, the file system structure of the data structure associated with the discardable file is marked to indicate that the file is a discardable file. In other implementations, the file itself is marked as a discardable file.

  The download manager determines a download condition associated with the request to store the discardable file in the storage area of the storage device, and the download manager determines the discardable file to the storage device based on the determined download condition. Decide whether to delay the download. The download manager manages the download of the discardable file to the storage device based on the decision whether to delay the download of the discardable file to the storage device. In some implementations, the download manager can delay the download of the discardable file to the storage device until the parameters associated with the download conditions are met. A storage allocator that can include a download manager then manages the storage of the downloaded discardable file in the storage area of the storage device based on the marking of the file being a discardable file.

  Various representative embodiments are illustrated in the accompanying drawings with the intention that the examples are not limiting. For the purpose of simplifying the figure, it should be understood that the components referred to below and shown in the figure are not necessarily drawn to scale. Also, where considered appropriate, reference numerals may be repeated in the figures to indicate similar, corresponding or similar components. The attached drawings are as follows.

1 is a block diagram of a storage system according to one embodiment. FIG. 6 is a block diagram of a storage system according to another embodiment. 2 is a block diagram of a storage allocator according to one embodiment. FIG. 1 is a method of managing files according to one embodiment. 1 is a method of managing storage of a discardable file in a storage device according to one embodiment. 2 is a method for marking one or more unsolicited files in a FAT32 structured file system according to one embodiment. This is a typical directory area associated with the FAT32 table. 4 is a FAT32 table according to one embodiment. 4 is an NTFS table according to one embodiment. 2 is a logical image of a FAT-based file system according to one embodiment. 3 illustrates a file storage management method according to the present disclosure. A representative primary FAT is shown. A representative discardable FAT is shown. 3 is a flowchart of a method for managing a storage device using a primary FAT and a discardable FAT. 3 is a flowchart of a method for managing a storage device using a FAT and a database. 3 is a flowchart of a method for managing a storage device using a FAT and a location file. A representative FAT that includes a cluster chain and in which the order of two or more clusters that make up the cluster chain is scrambled is shown. A representative FAT and associated location file is shown, the FAT includes a cluster chain, and the order of two or more of the clusters that make up the cluster chain is scrambled. 3 is a flowchart of a method for managing a storage device using a FAT in which the order of two or more clusters constituting a cluster chain is scrambled. 10 is a flowchart of a method of using a conversion lock to prevent conversion of a discardable file when the discardable file is open in a file system that implements a primary FAT and a discardable FAT. A representative bit mask user ID in the file system is shown. Shows the client-side component of the smart cache. Fig. 5 shows a file system structure for a discardable file modified for smart cache HD. It is a block diagram of the large file manager used for a smart cache HD system. FIG. 6 depicts a conversion flow for a large discardable file. It is a flowchart which shows the method of processing a conversion request with a large file manager. FIG. 6 depicts a Matroska file structure as an example of a file that can be split. It is the figure on which the divided Matroska file was drawn. 4 is a flowchart of a method for managing download of a discardable file to a storage area of a storage device.

  The following description provides various details of representative embodiments. However, this description is not intended to limit the scope of the claims, but is intended to illustrate various principles of the invention and how it may be implemented.

  To handle unsolicited content and related issues, user files are given storage priority over other files, and a storage usage safety margin is maintained to guarantee that priority. The “user file” is a file that has been stored by the user of the storage device or approved to be stored in the storage device. For example, a music file that a user downloads to his / her storage device is considered a user file. A user file is considered a “billing” file because it has been requested or approved to be stored by the user.

  The “other files” are referred to herein as “issuer file” and “unsolicited file”. The “issuer file” is a file stored in the storage device even though the user has not requested it and has not noticed it at least for a while. The user may not want to use an unsolicited file. Unused unsolicited files tend to consume expensive storage space on the user's storage device. Thus, in accordance with the principles disclosed herein, such files are allowed to be stored in the storage device only if storing them does not reduce the storage use safety margin. Storage priority is granted to user files by maintaining free storage space (ie, storage usage safety margin) reserved for future user files. A storage usage safety margin must be maintained to ensure that user files can be stored in the storage device whenever necessary or desirable.

  If for some reason the storage usage safety margin becomes narrower than desired, one or more unsolicited files are removed (ie, deleted) from the storage device to restore the storage usage safety margin. Maintaining a storage usage safety margin guarantees storage space for additional user files when additional user files are downloaded to the storage device. For this purpose, unsolicited files are marked as “disposable” in the structure of the storage file system and, if necessary, to recover at least the free storage space necessary to maintain the storage usage safety margin. Will be removed later.

  The probability that a user will use different discardable files may vary from one discardable file to another, so each unsolicited file (ie, each discardable file) is associated with the probability of using that file, the use of that file A discard priority level is pre-assigned according to one or more criteria such as expected revenue, size of the file, type of the file, location of the file, age of the file. For example, the discard priority level can be determined by the revenue potential. In another example, a movie trailer or advertisement has a higher discard priority than an actual movie because users typically do not want to see movie trailers and advertisements. In another example, one or more disposable files that are most likely to be used by a user are assigned the lowest discard priority level, and such files are least likely to be removed from storage. It means that. In other words, the higher the use probability of a discardable file, the lower the level of discard priority assigned to that file. If the desired storage usage safety margin is not fully recovered when one or more discardable files are removed, additional discardable files are removed from the storage device until the desired storage usage safety margin is recovered.

  Simply put, a data structure such as a file system implements a method for storing and organizing computer files. The file system includes a set of abstract data types and metadata that are implemented for data storage, hierarchical organization, manipulation, navigation, access, and retrieval. Abstract data types and metadata form a “directory tree” through which computer files (also referred to herein as “data files”, or simply “files”) can be accessed, manipulated and activated. A “directory tree” typically includes a root directory and optional subdirectories. The directory tree is stored in the file system as one or more “directory files”. The set of metadata and directory files included in the file system is referred to herein as the “file system structure”. Thus, the file system includes a data file and a file system structure that facilitates accessing, manipulating, updating, deleting, and activating the data file.

  The file allocation table (“FAT”) is a typical file system architecture. The FAT file system is used for various operating systems including DR-DOS, OpenDOS, MS-DOS, Linux, Windows (registered trademark), and the like. The FAT structured file system uses a table that concentrates information about which storage areas are free or allocated and where each file is stored on the storage device. In order to limit the size of the table, storage space is allocated to files in groups of adjacent sectors called “clusters”. As storage devices have evolved, the maximum number of clusters has increased and the number of bits used to identify a cluster has increased. The version of the FAT format is derived from the number of bits in the table. FAT12 uses 12 bits, FAT16 uses 16 bits, and FAT32 uses 32 bits.

  One other file system architecture is known as the New Technology File System ("NTFS"), currently NTFS is a later version of Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008, and Windows Vista. A standard file system of Windows NT including FAT 32 and NTFS is a typical file system that the storage device 100 can have.

  FIG. 1 shows a representative storage device 100. Storage device 100 includes a storage area 110 for storing various types of files (eg, music files, video files, etc.), some of which may be user files and others may be publisher files. The storage device 100 also includes a storage controller 120 that manages the storage area 110 via data and control lines 130. The storage controller 120 also communicates with the host device 140 via the host interface 150. The host device 140 can be dedicated hardware or a general purpose computing platform.

  The storage area 110 may be, for example, a NAND flash type. For example, the storage controller 120 controls the “read”, “write” and “erase” operations, wear leveling (wear smoothing), and the like, and controls communication with the host 140 to / from the storage area 110. All of the data transfer from the storage area 110 and the data transfer to / from the host device 140 are controlled. The storage area 110 includes, for example, user files and issuer files, protection data that is allowed to be used only by authorized host devices, and security data that is used only internally by the storage controller 120. be able to. A host (eg, host 140) cannot directly access the storage area 110. That is, for example, if the host 140 seeks or needs data from the storage device 100, the host 140 must request it from the storage controller 120. In order to facilitate access to data files stored in the storage device 100, the storage device 100 includes a file system 160.

  The storage area 110 is functionally divided into three parts: a user area 170, an issuer area 180, and a free storage space 190. The user area 170 is a storage space for storing user files in the storage area 110. The issuer area 180 is a storage space for storing the issuer file in the storage area 110. The free storage space 190 is an empty storage space in the storage area 110. Free storage space 190 may be used to accommodate user files or issuer files. When the user file is stored in the free storage space 190, the storage space containing the user file is subtracted from the free storage space 190 and added to the user area 170. Similarly, when the issuer file is stored in the free storage space 190, the storage space containing the issuer file is subtracted from the free storage space 190 and added to the issuer area 180. When a user file or issuer file is removed (ie, deleted) from the storage area 110, the released storage space is added to the free storage space 190 (returned).

  If the size of the free storage space 190 allows it, the user of the storage device 100 can download the user file from the host 140 to the storage area 110. The downloaded user file is stored in the free storage space 190, and as described above, the storage space containing the file is subtracted from the free storage space 190 and added to the user area 170. As explained previously, user files have priority over other (eg, issuer) files, and the desired storage usage safety margin is set to guarantee that priority, and if necessary, Recovery is achieved in the manner described below.

  Host 140 includes a storage allocator 144 for facilitating recovery of free storage space 190. Storage allocator 144 can be hardware, firmware, software, or any combination thereof. Generally, the storage allocator 144 determines whether the file (eg, file 142) transmitted to the host 140 is a user file or an issuer file, and the transmitted file is determined accordingly. Mark (ie, mark as non-disposable or disposable).

  If the storage allocator 144 determines that the file (for example, the file 142) transmitted to the host 140 is non-disposable because, for example, the file is a user file, the storage allocator 144 stores the file in the storage area 110. Store in a regular way. As previously described, storage space in the storage area 110 containing non-disposable files is added to or becomes part of the user area 170. However, if the storage allocator 144 determines that the file transmitted to the host 140 can be discarded, for example because it is an issuer file, the storage allocator 144 marks the file as discardable. In some implementations, in order to mark a file as discardable, the storage allocator 144 marks the file system structure in the file system 160 to indicate that the file is a discardable file. Should. In other implementations, the storage allocator 144 marks the file itself as a discardable file in order to mark the file as discardable. If the free storage space 190 is larger than the desired storage usage safety margin, the storage allocator 144 also stores the marked discardable file in the free storage space 190 and, as previously described, in the free storage space 190. The storage space that contains the discardable files is subtracted from the free storage space 190 (ie, the free storage space is reduced) and added to the issuer area 180 (this addition is logically shown as the discardable file 182). Have been).

  As previously described, the probability that an issuer file will be used by the user may vary from issuer file to issuer, so that the issuer file with the least use accuracy is the first candidate for removal from storage area 110. It becomes. Thus, in addition to marking files as non-disposable or disposable, the storage allocator 144 assigns a discard priority level to each discardable file before, simultaneously with, or after the discardable file is stored in the storage area 110. assign.

  By marking a file as non-disposable or discardable, the storage allocator 144 assigns a discard priority level, and by using the file system 160 (or its image) of the storage device 100, the storage allocator 144 is stored in the storage area 110. It also “recognizes” the number of user files and publisher files in it, as well as their size and logical location within storage area 110. Recognizing this information (ie, the number, size, and location of files), and based on one or more marked files, the storage allocator 144 may identify the storage area 110 and the billing files and unclaimed in the storage area 110. Manage file storage. The management of the storage area 110 or the management of the storage of files in the storage area 110 may be performed by, for example, selectively removing one or more files marked as discardable, recovering the storage use safety margin, and marking as discardable. May include freeing up storage by removing all files that have been processed, and remapping a cluster of files to a lower performance storage module. Management of storage area 110 or the files stored therein may include other or alternative aspects of management of storage area 110 or files stored therein.

  The storage allocator 144 recovers the free storage space originally reserved for future user files (ie, recovers the desired storage usage safety margin) according to the discard level assigned to each discardable file. It also recognizes the order in which discardable files can be discarded (ie, deleted or removed from storage area 110) or to be performed. Thus, the user wishes to store a new user file in storage area 110, but there is not enough free storage space to accommodate the user file (which means that the storage usage safety margin is narrower than desired). The storage allocator 144 will remove one disposable file to reclaim more free storage space (ie, to expand the free storage space 190) until the desired storage usage safety margin is fully restored. Use the discard priority level assigned to the discardable file to delete iteratively. As explained earlier, a fully recovered storage usage safety margin ensures a high probability that sufficient free storage space is reserved for future user files. Considering that a user may wish to use a stored discardable file at some point, a discardable file is therefore needed for a new user file for storage space containing that file. So that the discardable file is only removed or deleted from the storage device 100 in response to receiving a request to store a new user file. The storage allocator 144 may be embedded in or incorporated into the host 140, or may exist outside the host 140 (shown as a dashed box 144 ′) and outside the storage device 100.

  The storage allocator 144 has a representative image of the file system of the storage device 100 or a file system associated with the storage device 100. The storage allocator 144 uses the file system image of the storage device to mark the file as non-disposable or discardable and to assign a discard level to each discardable file. In one example, the file system includes FAT, in which case marking is done by setting one or more unused bits in the unused portion of the FAT entry associated with the file. Because different file systems have different structures, file marking (ie, as non-disposable or disposable) and discard level, as described and described in detail below in connection with FIGS. The allocation is adapted to the file system structure used.

  FIG. 2 is a block diagram of a portable storage device 200 according to another embodiment. The storage controller 220 functions similarly to the storage controller 120, and the storage allocator 244 functions similarly to the storage allocator 144. Storage allocator 244 can be hardware, firmware, software, or any combination thereof. Storage allocator 244 cooperates with storage controller 220 internally. Each time the storage controller 220 receives a storage request from the host 240 that stores the file in the storage area 210, including an indication of whether the file is a discardable file, the storage controller 220 Further, the storage allocator 244 is informed whether the file can be discarded. Storage allocator 244 then marks the file as non-disposable or disposable in the structure of the file system associated with storage device 200. Typically, an application executing on the host 240 determines that the file is a discardable file and sends a flag or other indication to the storage controller 220 indicating that the file is a discardable file. An application executing on the host 240 sends the flag or other indication as part of the storage protocol for requesting that the file be stored on the storage device. Examples of such storage protocols are POSIX file system functions or Java. Includes the use of io class trees.

  When the storage allocator 244 determines that a new file can be discarded, the storage allocator 244 assigns a discard priority level to the new file according to the file usage probability. The storage allocator 244 then evaluates the current size of the free storage space 290 and one or more disposable files are removed (ie, deleted) from the storage area 210 to make room for the new file. Decide what to do. If one or more files are to be removed from storage, the storage allocator 244 determines which file is the current candidate file for removal. Thereafter, the storage allocator 244 informs the storage controller 220 of the discardable file to be removed from the storage area 210, and in response to this notification, the storage controller 220 indicates one or more discardables indicated by the storage allocator 244. Remove the file. In certain configurations of portable storage device 220, storage allocator 244 may be functionally positioned between storage controller 220 and storage area 210. In configurations where the storage allocator 244 is functionally located between the storage controller 220 and the storage area 210, the storage allocator 244 or storage area 210 must assume some of the functions of the storage controller 220. In such a configuration, the storage area 210 is composed of memory units that communicate at a higher level than the flash NAND protocol.

  FIG. 3 is a block diagram of a storage allocator 300 according to one embodiment. The storage allocator 300 includes a memory unit 310, a processor 320, and an interface 330. Memory unit 310 may contain a file system structure or an image of the file system structure associated with a storage device (eg, storage device 200 of FIG. 2). The processor 320 manages a file system associated with the storage device. The interface 330 may be adapted to cooperate with the host as shown in FIG. 1 and also with the storage controller of the storage device, or with only the storage controller of the storage device as shown in FIG.

  The processor 320 receives a request to store a file in the storage area of the storage device via the interface 330 and allows the file to be discarded or non-discardable in the structure of the file system associated with the storage device cooperating with the storage allocator 300. Configured or adapted for marking. If the interface 330 is functionally attached to the storage controller 220 of FIG. 2 (thus receiving, for example, a SCSI command or a wrapped USB / MSC command instead of a file level command) The request is at a level far below the file level. That is, the received request is a request to store a sector at a logical block address that will correspond to the file if properly interpreted by the host. If the storage controller 220 supports the NVMHCI protocol, or a networking file system protocol such as NFS or similar protocol, the storage controller 220 can receive file level requests. Thus, communication between a storage controller such as storage controller 220 and an interface such as interface 330 is not limited to implementations such as NVMHCI or NVMHCI. Communication interface 330 may be integral to storage allocator 300, as shown in FIG.

  The processor 320 is further configured or adapted to send the marked file to the storage device, and marking the file as discardable includes assigning a discard priority level to the file. If the file system used by the storage device is FAT-based, the processor 320 assigns a discard priority level to the marked file and the m top (ie top) levels in the FAT corresponding to the marked file. ) Bits (eg, m = 4) are assigned by setting the corresponding value. Its corresponding value set in the most significant bit in the FAT entry, or the value set in the NTFS directory entry, or it can be associated with the attributes of the file. “Attribute” means a metadata tag or some data structure containing information related to the type of content stored in the table in the header of the FAT table or NTFS table. “Advertising”, “premium content”, and “promotional (free) content” are representative types of content that can be stored in a FAT table or NTFS table. Alternative criteria for setting the discard level are, for example, last accessed file, file size, file type, and the like.

The number m of the most significant bits of the FAT32 entry dedicated to marking the file may be 4 or less. This is because these bits are not used. Furthermore, if more bits are used, more discard priority levels can be used. For example, using 3 bits (ie, m = 3) provides 8 (2 ³ = 8) discard priority levels, and using 4 bits (ie, m = 4) provides 16 (2 ⁴ = 16). ) Discard priority levels are provided (ie, include a discard priority level of “0”, which is assigned to non-discardable files). In other words, processor 320 sets the value of the m most significant bits to 0 if the file being marked is non-discardable and 1 and 2 ^m −1 if the file being marked is discardable. Set to a value between. The discard priority level indicates the priority with which the marked file can be discarded from the storage device or should be discarded. For example, depending on the implementation, the value “1” may indicate a file that can be discarded with the lowest priority or highest priority, and the value “2 ^m −1” may have the highest priority or lowest priority. Each file that can be discarded can be shown in order.

  The processor 320, as previously described in connection with the accuracy or probability that an unsolicited file will be used by the user of the storage device, depends on the file being marked, depending on the expected use of the file: A discard priority level can be assigned. The processor 320 can update the discard priority level of the marked file with each request to store a new file in storage or in response to receiving each request. The processor 320 can update the discard priority level of a given marked file independently of one or more new requests to store the file in storage. For example, a file that was previously of high priority can be lowered in priority after a certain time interval. The processor 320 deletes the file stored on the storage device if the file is associated with a discard priority level equal to or greater than a predetermined discard threshold. The processor 320 sets (resets) the discard threshold based on the number of file writes or appends, or depending on the expected use of free storage space on the storage device or the availability of a new issuer file. Can do.

  The memory unit 310 can accommodate an assignment table 340 that includes discard priority levels assigned by the processor 320 to files stored in the storage device. Furthermore, the allocation table 340 can contain file identifiers and information that associates files with discard priority levels assigned to files. The allocation table 340 can further accommodate a discard threshold. The information contained in the allocation table 340 allows the processor 320 to identify which one or more disposable files can be removed from the storage device to recover the desired storage usage safety margin.

  In response to receiving a request to store a new file in the storage device, the processor 320 evaluates the size of the free storage space (f) on the storage device, and the estimated size of the free storage space on the storage device. If it is larger than the predetermined size, the new file is stored in the storage device, but if it is not larger than the predetermined size, the processor 320 looks for one or more disposable files in the storage device that can be deleted and Upon finding one or more files, the processor 320 expands the current free storage space (f) so that the total size of the extended free storage space is equal to or greater than the predetermined size. Delete the file or files. The one or more discardable files are stored if the discard priority level associated with the discardable file is equal to or greater than a predetermined discard threshold (eg, between 1 and 15, eg, 15). It can be deleted from the device.

  After the free storage space is sufficiently expanded, the processor 320 allows new files to be stored in the expanded free storage space. “Free storage space is expanded sufficiently” means that the total free storage space can accommodate new files without reducing the desired storage safety margin, or equivalent, but has been expanded. Free storage space by releasing the occupied storage space one by one until the total size of the free storage space is equal to or larger than the predetermined size or until all discardable files are removed Means to spread.

  The processor 320 may be a standard ready-to-buy system-on-chip (“SoC”) device, or a system-in-package (“SiP”) device, or dedicated software that performs the steps, operations, and evaluations described herein at runtime. Can be a general-purpose processing apparatus. In the alternative, the processor 320 may be an application specific integrated circuit (“ASIC”) that performs the steps, operations, and evaluations described herein by using hardware.

  FIG. 4 is a method of storing a discardable file according to one embodiment. FIG. 4 is described in conjunction with FIG. In step 410, the host 140 receives a request to store the file 142 in the storage device 100. In step 420, the storage allocator 144 marks the file as “disposable” or “non-disposable”, and if the free storage space 190 is large enough, the storage controller 120 of the storage device 100 stores the marked file in step 430. (I.e., for storage in storage area 110). The file is also marked in the sense that a discard priority level is assigned to the file. At step 440, the storage allocator 144 may store the storage area 110 (through communication with the storage controller 120) based on the marked file, and optionally based on one or more files that have already been marked. Alternatively, the files stored in the storage area 110 are managed.

  FIG. 5 is a method for managing storage of discardable files in a storage device according to one embodiment. FIG. 5 is described in connection with FIG. The new file is a candidate stored in the storage device 100. Recognizing the current image of the file system 160 of the storage device 100, the storage allocator 144 at step 510, the free storage space 190 whose current size is f is the new file (ie, a candidate that is likely to be stored). File) can be examined to evaluate the current size “f” of the free storage space 190. In general, the way the storage allocator 144 processes a new file depends on whether the new file is a user file or an issuer file. Accordingly, the storage allocator 144 first determines whether the new file is a user file or an issuer file.

If the new file is a user file, at step 520, the storage allocator 144 checks whether the free storage space 190 can accommodate the new user file. If the free storage space 190 can accommodate the new user file (indicated as “Y” in step 520), the storage allocator 144, in step 560, stores the new user file to store the desired storage usage safety. A new user file is stored in the free storage space 190 regardless of whether the margin is narrowed or not. Even though the storage allocator 144 stores the new user file in the free storage space 190, the desired storage usage safety margin becomes narrower (ie, compared to the desired storage usage safety margin), the storage allocator 144 will Take no further action on storing the file.

  However, if the desired storage usage safety margin becomes narrower after the storage allocator 144 stores the new user file in the free storage space 190, step 550 is stored to maintain the desired storage usage safety margin. Additional steps are included in which the storage allocator 144 determines which discardable files are to be deleted first, which discardable files are to be deleted second, and so on. The storage allocator 144 determines which discardable file should be deleted first, which should be deleted second, etc., based on the discard level assigned by the storage allocator 144 to the stored discardable file. judge.

  If the storage allocator 144 determines in step 520 that the free storage space 190 cannot accommodate a new user file (shown as “N” in step 520), the storage allocator 144, in step 530, discards the free storage space 190 and discards it. When combined with the storage space occupied by a possible file, it is determined whether it is sufficient to store the new user file. If the combined storage space is insufficient (indicated as “N” in step 530), no matter how many discardable files are deleted, the new user file will have a size that is greater. It means that it cannot be stored in the “non-user” storage area because it is large. If the combined storage space is sufficient (indicated as “Y” in step 530), the storage allocator 144 is stored to free up sufficient storage space for the new user file. In step 540, which discardable files are discarded can be deleted. As previously described, the storage allocator 144 marks the files in the storage device's file system as non-disposable or disposable, so that the storage allocator 144 uses the storage device's 100 file system to create these discardable files. Search for. In addition, the discard levels assigned by the storage allocator 144 to the marked file are also embedded in the storage file system so that each discard level is associated with a corresponding marked file.

  Upon finding a discardable file (“DF”) to be discarded first (this file is hereinafter referred to as “DF1”), the storage allocator 144 determines that storage space (this storage space is hereinafter referred to as “SP1”). File DF1 is deleted to add or return to storage space 190.

  Thereafter, at step 550, the storage allocator 144 checks whether the expanded free storage space 190 (ie, free storage space 190 + the last storage space returned, ie, f + SP1) can accommodate the new user file. If the expanded free storage space 190 (ie, f + SP1) still cannot accommodate the new user file (shown as “N” in step 550), the storage allocator 144 allocates additional storage space to the free storage space 190. Step 550 is repeated iteratively (i.e., by finding and deleting the next discardable file to be deleted) (iteration is indicated by 555).

  Upon finding the next discardable file with the second highest discard priority (the next discardable file is hereinafter referred to as “DF2”), the storage allocator 144 determines that the additional storage space (this additional storage space is The file DF2 is deleted in order to release and add to the free storage space 190 (hereinafter referred to as “SP2”). Thereafter, at step 550, the storage allocator 144 checks again whether the expanded free storage space 190 (ie, free storage space 190 + two last freed storage spaces, ie f + SP1 + SP2) can accommodate the new file. If the expanded free storage space 190 (ie, f + SP1 + SP2) still cannot accommodate the new file (shown as “N” in step 540), the storage allocator 144 is the next discardable to be deleted. Repeat step 540 once more to find the file. The storage allocator 144 repeats steps 540 and 550 until the accumulated free storage space 190 can accommodate the new user file (shown as “Y” in step 550). Thereafter, in step 560, the storage allocator 144 stores the new user file in the storage area 110.

  As described above, if the actual storage usage safety margin becomes narrower than the desired storage usage safety margin after the storage allocator 144 stores the new user file in the free storage space 190, step 560 may include the desired storage usage safety margin. Including additional steps for the storage allocator 144 to determine which stored discardable file should be deleted first, which discardable file should be deleted second, etc. it can.

If the new file is an issuer file If the new file is an issuer file, then the storage allocator 144 will only allow the free storage space 190 to accommodate the new issuer file without reducing the desired storage usage safety margin. The new issuer file is stored in the storage area 110 (at step 560). That is, if storing a new issuer file results in a reduction in the desired storage use safety margin, the storage allocator 144 can determine not to store the new issuer file in the storage area 110. In such a case, storage allocator 144 may refrain from taking action on the file and delete the file from storage to free up storage space for the new issuer file. Alternatively, the storage allocator 144 can delete at step 540 one or more higher priority discardable files to free up storage space for the discardable files having a lower discard priority. As previously mentioned, the method in which a file is marked in the file system of storage device 100, the discard level is embedded in the file system of storage device 100, the file is marked, and the discard level is embedded in the file system is Depends on the file system being used, or can be adapted to the file system used.

  FIG. 6 is a method for marking an unsolicited file in a FAT32 structured file system according to one embodiment. The FAT32 structured file system uses clusters. As previously described in connection with the FAT32 structured file system, the number of bits used to identify a FAT32 cluster is thirty-two. FIG. 6 is described in connection with FIG.

  In step 610, the m most significant bits (where m ≦ 4) of the 32 bits of each cluster of FAT32 are used to mark the file as non-disposable or discardable depending on the situation, and each Assigned or dedicated to hold a discard level corresponding to a discardable file. Assigning a discard level to a file is done by setting the corresponding value to the assigned m bits corresponding to the marked file.

  At step 620, the storage allocator 144 evaluates the level of certainty that the user of the storage device 100 will use the unsolicited file. Evaluation of the accuracy of using the file can be performed in various ways known to those skilled in the art of commissioned files. For example, the assessment of accuracy using the file can be based on monitoring the location of the person using the storage device and / or the previous experience and preferences of the monitored user. For example, the type of content stored in the FAT table or NTFS table (for example, “advertising content”, “premium content”, “promotional (free) content”, etc.) May be based on The storage allocator 144 can use alternative or additional criteria to evaluate the likelihood that the file will be used. For example, file attributes or features can be used that can be, or can be associated with, the last accessed file, the size of the file, the type of file, and the like.

  After the storage allocator 144 evaluates the level of accuracy that the user will use the unsolicited file, the storage allocator 144 assigns a discard priority level that corresponds to the estimated accuracy level of unsolicited file use at step 630. The higher the probability that the unsolicited file will be used by the user of storage device 100, the lower the discard level.

  If m is equal to 4 bits, this provides 15 discard levels with a discard scale of 1 (ie 0001) to 15 (ie 1111). That is, discard level 0 is assigned to all non-discardable files, discard level 1 is assigned to the discardable file with the lowest discard priority, and discard level 15 is assigned to the discardable file with the highest discard priority. It is done. After the storage allocator 144 assigns a discard level corresponding to the unsolicited file, the storage allocator 144, in step 640, is between 1 and 15 in the four most significant bits of the cluster associated with the unsolicited file. Set the corresponding value of. If the unsolicited file is associated with more than one cluster, the four most significant bits of each cluster are set to the same value.

  In step 650, it is checked whether the unsolicited file is the last file that needs to be evaluated. If the unsolicited file is not the last file that needs to be evaluated (indicated as “N” in step 650), other files are evaluated in the manner described previously. If the unsolicited file is the last file that needs to be evaluated (indicated as “Y” in step 650), the unsolicited file is for each of its values set in step 640. Of m bits to the storage device.

  FIG. 7 is a representative directory table 700 associated with the FAT32 table. Since the directory table 700 is a partial table used for illustration, the table 700 does not show all the fields of the FAT directory entry. Directory area 700 contains file details stored in the associated file system, such as file name, file size, and where in the associated storage space each file begins. File details are contained in the following fields: Field 710 contains the disk operating system ("DOS") file name of the file stored in the associated file system, field 720 contains the file extension, and field 730 contains various attributes of the file. Field 740 contains the upper 16-bit word of the first cluster number ("FCN") of the file, field 750 contains the lower part of the first cluster number ("FCN") of the file, and field 760 Contains the size of the file. Each FCN number indicates the first logical cluster in which the file can be found.

  The first entry in the directory area 700 contains information about a representative file called “REALFILE” (shown at 770). REALFILE 770 has the file extension “DAT”, its FCN is “0000 0002” (shown at 755), and its size is “0000 24E4”. The numbers in the table 700 are shown as hexadecimal values. As part of the standard, the attribute values “00” (shown at 780) and “20” (not shown in FIG. 7) refer to the “regular” file, and the attribute value “02” A file that is hidden in the file system. The file name “\ xE5Config” indicates a deleted file, where “\ xE5” means that the value of the first byte of the file name is hexadecimal E5. By way of example, FCN number 0000 0002 (shown at 755) indicates the first cluster of the file REALFILE.

  FIG. 8 is an exemplary partial FAT32 table 800 according to one embodiment. The FAT32 table 800 is shown as a double word (“DWORD”) array, and the values are hexadecimal values. Reference number 810 indicates the type of device containing the FAT32 table 800, where “F8” refers to the hard disk. The FAT32 table 800 is referred to as cluster # 1 (shown at 820), cluster # 2 (shown at 825)... Cluster # 23 (shown at 830). Includes 23 clusters. FIG. 8 is described in conjunction with FIG. The cluster in the FAT32 table 800 can be the first cluster of the file, can point to the next linked cluster of the file, or can be an end of file (“EOF”) indication. it can.

  Referring back to the directory area 700, the first FCN of the file REALFILE (shown at 770) is “0000 0002” (shown at 755), which is the table 800 of FIG. Cluster # 2. As shown in FIG. 8, the value of cluster # 2 (ie, the value “0000 0003”) refers to cluster # 3 (shown at 840), which is the cluster for the next file. . Similarly, the value of cluster # 3 (ie, “0000 0004”) refers to cluster # 4, which is the cluster for the next file. Cluster # 4 has the value “0FFF FFFF” (“F” is a hexadecimal digit representing the decimal value “15”), where “FFF FFFF” (shown at 850) Indicates an EOF indication of the file, and a zero value (shown at 860) indicates a discard level of zero. Thus, the file REALFILE is associated with three clusters (ie, cluster # 2, cluster # 3, and cluster # 4).

  As explained previously, discard level 0 is assigned to non-discardable files. Note that the most significant hex digit of each cluster in a particular file is set to the same discard priority level assigned to that file. For example, the file REALFILE is assigned a discard level “0”, so each of the most significant hexadecimal digits of clusters # 2, # 3, and # 4 has its value (ie, the value “0”, these “ 0 ”values are underlined). In another example, the discard priority level “1” is assigned to the file “E5Config” whose FCN is “0000 0005” (as shown in FIG. 7). Thus, the most significant hexadecimal digit of each of clusters # 5-12 belonging to that file has the value “1” (eg, as shown at 870). In other words, as disclosed herein, the most significant hexadecimal digit of a cluster associated with a particular discardable file, or equivalently, the most significant 4 bits, is the discard priority level assigned to that particular file. Is set to the same value corresponding to. As previously described, the number m of the most significant bits used to indicate the discard priority level may be different from 4 (ie, m ≦ 4).

  FIG. 9 is an exemplary partial NTFS table 900 according to one embodiment. The NTFS table 900 accommodates file details such as file name and file size. The NTFS table 900 includes a data field 910 that contains “regular” data (eg, data 920) for files that change according to a “normal” data flow. In the disclosure herein, the NTFS table 900 also includes a “discard information” field 915 to contain discard information (eg, discard information 930) for each evaluated file. The discard information field 915 can also include information other than the discard priority level. For example, the discard information field 915 can include information regarding the server that supplied the file and the expiration date after which the file must be discarded. Unlike FAT-based file systems, NTFS-based file systems do not limit the discard value assigned to a discardable file to the maximum number defined by a set of bits. This means that the range of discard values can be chosen freely. For example, the discard value can range from 1 to 25. NTFS is a typical non-FAT file system. In general, the corresponding discard value can be set in a data field in a non-FAT based file system entry corresponding to the marked file.

  FIG. 10 is a logical layout of the storage device file system 1000 according to one embodiment. A storage allocator (eg, storage allocator 144 of FIG. 1) may hold a storage device file system 1000 or an image of the file system 1000 that cooperates with it, or the storage allocator may have access to the file system 1000.

  The file system 1000 includes a boot section 1010, a FAT 1020 associated with the file system 1000, a directory table 1030, a file area 1040, and a discardable file area 1050. The FAT 1020 includes a discardable file allocation area 1025 that includes the discard priority level of the discardable file. Directory table 1030 includes access information for accessing all files stored in the storage device (ie, discardable files and / or non-discardable files). The file area 1040 includes non-disposable files. The index and database area 1045 contains an index for a discardable file and further metadata associated with the discardable file. The index and metadata contained in the index and database area 1045 are used to calculate the discard level, but are not required during the actual discard process. The discardable file area 1050 contains a discardable file.

  FIG. 11 illustrates a file management method according to the disclosure herein. FIG. 11 is described in conjunction with FIG. It is assumed that two user files (ie, files “F1” and “F2”) are initially stored in storage area 110 at time T0. Since the files “F1” and “F2” are user files, they are stored in the user area 170 and the discard level assigned to them by the storage allocator 144 is zero. The total storage capacity of the storage area 110 is T (shown at 1110), and the files F1 and F2 are stored in the storage device 100, so the size of the remaining free storage space 190 (see FIG. 1) ) Is f (shown at 1120). Assume that the issuer wishes to store three unsolicited files in storage area 110. As previously described, storing the issuer's three unsolicited files in storage area 110 results in the desired storage usage safety margin reserved for future user files (shown at 1130). Storage allocator 144 evaluates the size of the free storage space 190 in the storage device 100 (ie, f at 1120). If storing the issuer's three unsolicited files reduces the storage usage safety margin 1130 (ie, the desired storage usage safety margin), the storage allocator 144 refrains from storing those files.

  In this example, the storage allocator 144 determines that the three unsolicited files of the issuer can be stored in the storage area 110 without reducing the storage usage safety margin 1130. Accordingly, at time T1, the storage allocator 144 allows the storage controller 120 to store the three unsolicited files of the issuer in the storage area 110. The unissued files of the three issuers are referred to as “P1”, “P2”, and “P3”. The storage allocator 144 further determines the probability that the files P1, P2, and P3 are used by the user of the storage device 100 and assigns a corresponding discard level to each of those files. The storage allocator 144 then stores the discard level assigned to the file in the FAT table as shown in FIG. 8 or the NTFS table as shown in FIG.

  At time T2, the user of storage device 100 wishes to store two more files (ie, files “F3” and “F4”) in storage area 110. The storage allocator 144 determines the size of the free storage space 190 in the storage device 100 (to determine whether there is sufficient storage space in the storage area 110 to store the additional files (ie, files F3 and F4). That is, f) at 1120 is evaluated again. In this example, the storage allocator 144 determines that the currently free storage space can accommodate the files F3 and F4. Accordingly, at time T2, the storage allocator 144 permits the storage controller 120 to store the files F3 and F4 in the storage area 110.

  Since the files F3 and F4 are user files, the user file has a higher storage priority than the issuer file regardless of how many times the user uses the files F3 and F4. And the probability that F4 is used by a user of storage device 100 is not critical. Accordingly, the storage allocator 144 assigns the discard level “0” to the files F3 and F4, and assigns the assigned discard level to the FAT table as shown in FIG. 8 or NTFS as shown in FIG. Store in a table.

  At time T3, the user of the storage device 100 desires to store another file (that is, the file “F5”) in the storage area 110. The storage allocator 144 determines the size of the free storage space 190 in the storage device 100 (ie, the storage space 110 to determine if there is sufficient storage space in the storage area 110 to store the additional file (ie, file F5)). Evaluate f) at 1120 again.

  In this example, the storage allocator 144 determines that the currently free storage space can accommodate the file F5. Therefore, at time T3, the storage allocator 144 permits the storage controller 120 to store the file F5 in the storage area 110. As shown in FIG. 11, storing the user file F5 narrows the storage use safety margin. That is, the free storage space f in the storage area 110 remaining after the files F1 to F5 and P1 to P3 are stored in the storage area 110 is smaller than the storage use safety margin 1130. Accordingly, the storage allocator 144 restores or restores the storage usage safety margin by removing one of the issuer's files (ie, P1, P2, and P3). As previously described, since the user file has the highest storage priority, the storage usage safety margin can be revived or restored by removing (ie, deleting) one or more publisher files. .

  As previously described, the determination of which issuer file or multiple issuer files should be removed from the storage area 110 is determined by the storage allocator 144 assigned to each stored disposable file. Performed by the storage allocator 144 based on the priority level.

  Referring to FIG. 11 again, it is assumed that the highest discard priority level (for example, 13) is assigned to the issuer file P3 among the stored issuer files P1 to P3. Accordingly, the file P3 is removed from the storage area 110 at the time T4, thereby increasing the free storage space 190. Since the size of the free storage space 190 at time T4 (ie, f at 1120) is larger than the storage usage safety margin 1130, it is not necessary to remove the issuer file any more.

  A user of storage device 100 may wish to remove one or more user files. At time T5, the user removed two of his files (ie, files F4 and F5), thereby further freeing up storage space 190. As described herein, re-acquisition of free storage space or recovery of the storage usage safety margin is performed by removing the required number of discardable files, so removal of files F4 and F5 is performed on free storage space 190. It is independent of size or storage usage safety margin. It is assumed that the issuer wishes to store one other unsolicited file in storage area 110. As described previously, the storage allocator 144 stores the issuer's unsolicited file in the storage area 110 to determine if the storage usage safety margin 1130 is reduced, ie, the size of the free storage space 190 (ie, Evaluate f) at 1120. If storing the issuer's new unsolicited file reduces storage use safety margin 1130, storage allocator 144 refrains from storing the file.

  In this example, the storage allocator 144 determines that the issuer's new unsolicited file (ie, file “P4”) can be stored in the storage area 110 without reducing the storage usage safety margin 1130. Accordingly, at time T6, the storage allocator 144 permits the storage controller 120 to store the issuer file P4 in the storage area 110. The storage allocator 144 also determines the probability that the file P4 will be used by the user of the storage device 100 and assigns a corresponding discard level to this file. The storage allocator 144 then stores the discard level assigned to the file P4 in the FAT table as shown in FIG. 8 or the NTFS table as shown in FIG. Each time a new file must be added to the storage area 110, the storage allocator 144 evaluates the current size of the free storage space 190 and which one or more issuer files (if any) are in the storage area 110. The process of storing the new issuer file and the new user file and removing the stored file may be continued while determining whether it should be removed from.

  Assigning a discard level to a discardable file can be based on the user's experience or selection, the user's global positioning system (“GPS”) location, and / or other criteria. For example, if a storage user seems to prefer a certain type of music (based on the previous user's experience), the storage allocator will put the file in the publisher's file If it contains music that is one of them, a relatively low discard priority level (eg, 3 on a scale from 1 to 15) can be assigned. However, if the publisher's music is disliked by the user (ie, based on the previous user's experience), the storage allocator will have a higher discard priority level (eg, 1-15) for its associated publisher's file. 12) of the scale can be assigned. The criteria used to assign a discard level to a discardable file are the expected usage of the file, the expected revenue associated with the use of the file, the type of the file, the size of the file, the file Location in the storage device, the age of the file, and other criteria or parameters specified herein. Other criteria, whether alone or in combination with any of the criteria mentioned herein, can be used in the same way, and a discard level assignment can be made using one or more criteria. In addition, different criteria may be used to assign discard levels to different discardable files.

  In another example, if an issuer wishes to send a user location-dependent advertisements (ie, advertisements related to products or services offered in a particular location), the storage allocator It is possible to assign a discard priority level that changes according to the position of the user to the advertisement of the issuer. That is, as the user moves away from a particular location, the disposal level will increase, but the further away from the particular location, the more interested the user will consume the product or service provided at that particular location. This is because it can be assumed that the

  As previously described, the cluster chain for a discardable file is recorded in the FAT along with a flag that identifies the file associated with the FAT32 entry as a discardable file. Typically, flags are present in the four most significant bits of each FAT32 entry. A cluster chain can be assigned to discardable files but has no non-discardable files associated with them, so chkdsk or fsck. It can happen that a utility such as vfat converts a discardable file into a non-discardable file, also known as a “real” file, thereby reducing the security of the file system 160. Furthermore, there is a risk that some FAT recovery utility will reset the discardable file flag in the FAT32 entry. FAT32 file system inspection and repair utilities often step through the file system and apply rules to correct common errors. In general, these utilities can look for cluster chains in the FAT that do not have a corresponding entry in the first cluster number (FCN) column in the directory table. The utility treats cluster assignments in the FAT that do not have any directory or file entries as unknown data fragments (also known as orphan clusters), and the utility either deletes these orphan clusters, or A corresponding file entry can be created in the directory table. The discardable file system described herein can use what would otherwise be considered an orphan cluster, so the utility mistakenly made a discardable file a non-discardable file. May change or completely remove a discardable file.

  To address these issues, in some implementations, the storage allocator 144 can associate a discardable file with a cluster chain in the primary FAT, which hides the physical location of the discard file, Storage allocator 144 stores the physical location of the file in a discardable FAT, database, or one or more location files. Typically, the discardable FAT, database, or one or more location files are invisible to the primary FAT, and in some implementations, the host operating system can configure the discardable FAT, database, or one or more location files. An attribute associated with that discardable FAT, database, or one or more location files that prevents access to the file may be enabled.

  As noted above, each entry in FAT32 is 32 bits, but only the lower 28 bits are used. Typically, the upper 4 bits are left unused and set to zero. (FAT32 compliant implementations are required to ignore the upper 4 bits, even if they are set in the assigned cluster, and to set the upper 4 bits to zero when writing a new FAT entry. The discardable file is distinguished from the non-discardable file by a flag in the upper 4 bits of the FAT entry of each cluster chain associated with the file. The standard FAT32 driver considers discardable files as allocated space and does not write over them. However, the storage allocator 144 can periodically perform operations such as those previously described with respect to FIG. 5 to maintain free space allocation in the storage device 110, and the space allocated to the discardable file. Can be recovered.

  By utilizing a primary FAT and at least one of a discardable FAT, a database, and one or more location files, the primary FAT can be expanded. When the extended primary FAT is used in conjunction with a branch of the file allocation table lookup logic, a discardable FAT, database, or one or more location files if the upper 4 bits of the FAT entry are non-zero Information representing the physical location of the discardable file is used instead of the FAT entry of the primary FAT. Since information in the discardable FAT, database, or one or more location files overrides the value in the FAT entry of the primary FAT, chkdsk and fsck. Utilities such as vfat do not turn a discardable file into a non-discardable file, but the utility associates a cluster of discardable files with a discardable FAT, a database, or a directory or file entry in one or more location files. It is because it is regarded as being done. In addition, the FAT recovery utility does not reset the flag in the FAT32 entry indicating that the file is a discardable file, but it does not reset the chkdsk and fsck. A utility such as vfat is associated with a directory or file entry in a discardable FAT, database, or one or more location files, rather than considering the cluster associated with the discardable file as free space. Because it is considered to be.

  When the file system 160 uses the primary FAT 1200 and the discardable FAT 1201 to store a file marked as a discardable file, the storage allocator 144 sets the cluster chain 1202 assigned to the discardable file as a file. Update the primary FAT 1200 as shown in FIG. 12a for association. In general, cluster chain 1202 may be the same size or larger than the discardable file associated with cluster chain 1202. In some implementations, the cluster chain 1202 masks the physical location of the discardable file in the primary FAT. Typically, as previously described with respect to FIGS. 7 and 8, each cluster in the cluster chain starting from entry 1204 is a cluster chain until a value such as 1FFF FFFF shown in entry 1206 indicates the end of cluster chain 1202. Refers to the next continuous cluster of 1202. However, in other implementations, each cluster in the cluster chain has a value such as 1FFF FFFF indicating that the cluster is an individually assigned cluster rather than pointing to the next consecutive cluster in the cluster chain. be able to.

  As shown in FIG. 12 b, the first entry 1204 in the cluster chain 1202 points to the corresponding entry 1208 in the discardable FAT 1201. As previously described with respect to FIGS. 7 and 8, for each file, each cluster in the cluster chain 1202 in the discardable FAT 1201 until the value such as 1FFF FFFF shown in entry 1210 indicates the EOF of the file. Points to the next sequential cluster in the file.

  It should be understood that a cluster chain 1202 can be associated with more than one file. For example, as shown in FIG. 12b, the cluster chain 1202 includes a first set of clusters from cluster # 6 (element 1208) to cluster # 9 (element 1210) for the first file 1212. , Including a second set of clusters from cluster # 10 to cluster # 11 for the second file 1214.

  Further, it should be understood that a primary FAT 1200 and a corresponding discardable FAT 1201 may include more than one cluster chain. For example, as shown in FIGS. 12a and 12b, the primary FAT can include a cluster chain 1202 from cluster # 6 to cluster # 11, and a second cluster chain from cluster # 20 to cluster # 22. 1216 can be included.

  In other implementations, rather than using a primary FAT 1200 and a discardable FAT 1201, the file system may utilize the primary FAT 1200 to associate one or more files with the cluster chain, as described above. A database or one or more separate location files can be utilized in place of the discardable FAT to store the physical location of one or more discardable files associated with the cluster chain. The database or location file can be a text file or a binary file stored in a non-disposable area of the file system.

  FIG. 13 shows a method for managing a storage device using a primary FAT and a discardable FAT. FIG. 13 is described in conjunction with FIG. In step 1310, the host 140 receives a request to store the file 142 in the storage device 100. In some implementations, the storage allocator 144 derives a request to store the file 142 in the storage device 100 based on one or more write requests associated with the file.

  At step 1320, storage allocator 144 marks the file as “disposable” or “non-disposable” in the file system structure associated with storage device 100 as previously described. At step 1320, the file is also marked in the sense that a discard priority level is assigned to the file.

  In step 1330, when the file is a discardable file, the storage allocator 144 updates the primary FAT to associate the cluster chain assigned to the file with the file. At step 1340, the storage allocator 144 updates the discardable FAT to represent the physical location of the file in the storage device 100. In step 1350, the storage allocator 144 manages the storage area 110 of the storage device 100 (through communication with the storage controller 120) or discards the files stored in the storage area 110 based on the marked files. Manage according to possible FAT. Storage area management is similar to that previously described in connection with FIG.

  FIG. 14 shows a method for managing a storage device using a FAT and a database. FIG. 14 is described in conjunction with FIG. In step 1410, the host 140 receives a request to store the file 142 in the storage device 100. At step 1420, the storage allocator 144 marks the file as “disposable” or “non-disposable” in the file system structure associated with the storage device 100 as previously described. At step 1420, the file is also marked in the sense that a discard priority level is assigned to the file.

  In step 1430, when the file is a discardable file, the storage allocator 144 updates the FAT to associate the cluster chain assigned to the file with the file. At step 1440, the storage allocator 144 updates the database to represent the physical location of the file in the storage device 100. In step 1450, the storage allocator 144 manages the storage area 110 of the storage device 100 (through communication with the storage controller 120) or manages the files stored in the storage area 110 based on the FAT and database.

  FIG. 15 shows a method for managing a storage device using a FAT and a location file. FIG. 15 is described in conjunction with FIG. In step 1510, the host 140 receives a request to store the file 142 in the storage device 100. At step 1520, storage allocator 144 marks the file as “disposable” or “non-disposable” in the file system structure associated with storage device 100 as previously described. At step 1520, the file is also marked in the sense that a discard priority level is assigned to the file.

  In step 1530, when the file is a discardable file, the storage allocator 144 updates the FAT to associate the cluster chain assigned to the file with the file. In step 1540, the storage allocator 144 updates the location file to represent the physical location of the file in the storage device 100. In step 1550, the storage allocator 144 manages the storage area 110 of the storage device 100 (through communication with the storage controller 120) or manages the files stored in the storage area 110 based on the FAT and location files. .

  In yet other implementations, the storage allocator increases security and prevents the file system from being corrupted or compromised by file system integrity utilities such as dosfsck (also known as fsck.vfat) or chkdsk. 144 can be discarded to ensure that the cluster chain cannot be reconstructed without reading the discardable FAT, database, or one or more location files that store the physical location of the discardable file Do not assign clusters sequentially to the cluster chain in the file area. In addition, utilities such as dofsfsck have been scrambled in the cluster chain to avoid changing a discardable file to a non-disposable file or resetting a flag in the upper bits of the file indicating that the file can be discarded. A range file associated with one or more of the existing clusters is generated in the FAT. In some implementations, attributes such as hidden attributes, system attributes, directory attributes, or volume attributes associated with the range file may be enabled to prevent the host operating system from accessing the range file.

  FIG. 16 is a chart showing a FAT that includes a cluster chain and in which the order of two or more clusters constituting the cluster chain is scrambled. As shown in FIG. 16, the clusters constituting the cluster chain starting from the entry 1602 are not continuous. For example, the order of the cluster chain starting from the entry 1602 is cluster # 13, cluster # 9, cluster # 7, cluster # 18, and cluster # 21. In this FAT, as previously described with respect to FIGS. 7 and 8, the value of each cluster points to the next cluster in the cluster chain.

  One or more range files that include one or more clusters in the cluster chain associated with the file, in addition to the scrambled order of the clusters that make up the cluster chain associated with the one or more files Can be created in FAT. In some implementations, each range file can represent all clusters in the range of clusters that are part of the cluster chain. Since the range file and the clusters constituting the cluster chain are related, chkdsk or fsck. Utilities such as vfat do not change a discardable file to a non-discardable file, and FAT recovery utilities do not reset the flag in the FAT32 entry indication that the file is a discardable file.

  FIG. 17 is a chart showing one or more range files created in the FAT, each of which stores at least one cluster in the cluster chain starting at entry 1602. For example, the first range file 1604 stores cluster # 7 and cluster # 9 from the cluster chain starting from entry 1602, and the second range file 1606 is cluster # 13, cluster from the cluster chain starting from entry 1602 # 18 and cluster # 21 are stored.

  A range file can store clusters from more than one cluster chain. For example, in addition to the clusters listed above from the cluster chain starting at entry 1602, the first range file 1604 may store cluster # 5 and cluster # 10 from the cluster chain starting at entry 1608. Similarly, in addition to the clusters listed above from the cluster chain starting from entry 1602, the second range file 1606 includes cluster # 16, cluster # 17, and cluster # 22 from the cluster chain starting from entry 1608. Can be remembered.

  FIG. 18 shows a method for managing a storage device using a FAT in which the order of two or more clusters constituting a cluster chain is scrambled. FIG. 18 is described in conjunction with FIG. In step 1810, the host 140 receives a request to store the file 142 in the storage device 100. At step 1820, storage allocator 144 marks the file as “disposable” or “non-disposable” in the file system structure associated with storage device 100 as previously described. At step 1820, the file is also marked in the sense that a discard priority level is assigned to the file.

  In step 1830, when the file is a discardable file, the storage allocator 144 updates the FAT to associate the cluster chain assigned to the file with the file. At step 1840, the order of two or more clusters in the cluster chain associated with the file is determined by determining the amount of memory in the storage device 100, the total size of the cluster chain, and the cluster between two consecutive clusters in the cluster chain. Flash memory management that can take into account the number and / or erase block size, the physical block address of each logical address within the allocated block, and / or wear leveling data for each page associated with the physical block address It is scrambled in the FAT based on factors such as an algorithm. In some implementations, the order of two or more clusters in the cluster chain is scrambled using a pseudo-random number generator or an entropic random number generator, with an offset within one range for each unassigned cluster. provide. In other implementations, the order of two or more clusters in the cluster chain is scrambled using a one-way hash function that takes into account non-deterministic values from host system 140 and / or storage device 100.

  At step 1850, a first range file is created in the FAT that includes at least one cluster in the cluster chain associated with the first file. In step 1860, the storage allocator 144 manages the storage area 110 of the storage device 100 (through communication with the storage controller 120) or manages the files stored in the storage area 110 based on the FAT and range files. .

  In yet other implementations, a conversion lock can be performed to ensure that the discardable file is not converted to a non-discardable file while it is open. For example, the discardable file is stored in the storage device 100 during the period when the discardable file is being downloaded to the storage device 100 or before the release date associated with a movie, song, or program associated with the discardable file. During the period before data associated with the discardable file is released to the public, such as when downloaded, the discardable file may be open. In general, the conversion lock serves to prevent a discardable file from being converted to a non-discardable file when the conversion lock is set.

  FIG. 19 shows a method of using a conversion lock to prevent conversion of a discardable file when the discardable file is open in a file system that implements the primary FAT and the discardable FAT. FIG. 19 is described in conjunction with FIG. At step 1910, the storage allocator 144 receives a request to convert a discardable file to a non-discardable file. At step 1920, storage allocator 144 identifies the value of the translation lock identifier associated with the discardable file. At step 1930, the storage allocator 144 determines whether the discardable file can be converted to a non-discardable file based on the value of the conversion lock identifier. Typically, the storage allocator 144 determines that a discardable file cannot be converted when the value of the conversion lock identifier indicates that the discardable file is open, and the storage allocator 144 discards the value of the conversion lock identifier. It is determined that the discardable file can be converted when the possible file indicates that it is not open.

  If the storage allocator 144 determines that the discardable file cannot be converted to a non-disposable file at step 1930, the storage allocator 144 prohibits marking the discardable file as a non-disposable file at step 1940. However, if the storage allocator 144 determines in step 1930 that the discardable file can be converted to a non-discardable file, the storage allocator 144 proceeds and in step 1950, the file is associated with the storage device 100. Mark the file as non-disposable in the system structure, update the primary FAT to represent the physical location of the file at step 1960, and update the discardable FAT to remove the physical location of the file at step 1970.

  It should be understood that a similar method is performed with a conversion lock when a database or location file is used with the primary FAT instead of the discardable FAT described above.

  In some implementations, an application is allowed to perform operations such as converting a discardable file to a non-disposable file or checking the value of a conversion lock identifier based on an identifier associated with the application. obtain. Typically, an application that creates or downloads a discardable file can associate a user identifier (ID) with the discardable file. The user ID may be an owner user ID that identifies the application or user that created the discardable file. In some implementations, the owner user ID is a 4-byte value.

  The file system 160 defines what additional user IDs associated with other users or applications can access the discardable file and what actions the additional user ID can take on the discardable file. Provides capability to the owner user ID. Depending on the usage of the discardable file, the additional user ID can be associated with a single application or a single user, or the additional user ID can be a shared user ID associated with multiple applications or multiple users. It should be understood that there can be.

  In some implementations, the owner user ID may allow an application associated with the additional user ID to access preview data associated with the discardable file. Although the preview data can be part of the discardable file, in other implementations the preview data is associated with the discardable file although it is separate from the discardable file. In one exemplary implementation, the discardable file is a movie, the preview data can include a movie trailer associated with the movie, the discardable file is a television program, and the preview data is a television program. The discardable file may be music data and the preview data may include a portion of the music data, or the discardable file may be a software program and the preview data may be a software program A demo version can be included. In other exemplary implementations, preview data cannot be accessed before the release date associated with the discardable file, but preview data associated with the discardable file is accessed. , After the release date, can be utilized so that both the discardable file and the preview data can be accessed. In another example, the owner user ID may allow an application associated with the additional user ID to write to the discardable file based on the user ID associated with the discardable file. .

  In some implementations, the file system can provide a permission bit mask for the owner user ID to define what operations the application associated with the additional user ID can perform on the discardable file. . An example of a permission bit mask for a typical usage scenario is shown in FIG. However, it should be understood that the owner user ID can override the permissions shown in FIG. 20 and assign arbitrary permissions to additional user IDs.

  Referring to the permissions shown in FIG. 20, an application whose property write permission bit 2004 is set enables or disables the conversion lock, sets a time stamp or consumes intention universal resource indicator (“URI”). ) Can be changed, and an application having the property read permission bit 2002 set can read attributes such as a conversion lock, a time stamp, or a consumption intention URI. An application in which the priority permission bit 2006 is set can change the priority level of the discardable file. An application for which the preview read permission bit 2008 is set can read preview data associated with the discardable file, and an application for which the preview write permission bit 2010 is set is associated with the discardable file. Preview data can be written. An application with the read permission bit 2012 set can read the discardable file, and an application with the write permission bit 2014 set can write to the discardable file. Typically, only the application associated with the owner user ID associated with the discardable file has these permissions. An application in which the conversion permission bit 2016 is set can convert a discardable file into a non-discardable file.

  The method disclosed herein of marking files and assigning discard levels to them in the associated file system can have many beneficial uses, one of which is the user file In particular, it is mentioned that the storage usage safety margin is restored in order to guarantee sufficient storage space. For example, the discard level assigned to a file can be used to remap the file cluster to a lower-level flash module or to clear the cluster on demand.

In addition to the method of managing data, also referred to as smart caching, described before smart caching for large files , filed December 16, 2008, both of which are hereby incorporated by reference. Pending US patent application Ser. No. 12 / 336,089 and pending US provisional patent application No. 61 / 159,034 filed Mar. 10, 2009 (Patent Document 4). In addition to the smart caching descriptions and features described in), a smart caching approach for large discardable files is provided. This large file smart caching, also referred to herein as smart caching HD, includes several changes and enhancements from the foregoing disclosure. Smart Caching HD intelligently handles splitting such files during conversion while maintaining their large (> 4 GB) status while they can be discarded, with support for files larger than 4 GB It differs from smart caching in that a large file manager is added. Specifically, it takes into account the management and retrieval of these files and their disposal as a single unit rather than as a series of smaller files.

The components smart caching components are described in the block diagram of FIG. The smart caching component 2100 can be operated in conjunction with any of a number of operating systems such as ANDROID, WINDOWS or LINUX. Alternatively, the smart caching techniques discussed herein can be performed on a storage medium such as a memory card that does not have an operating system. A new component added for smart caching HD is the large file manager 2102, which handles files larger than 4GB in size. The large file manager is described in more detail below.

Large Discardable Files A file system that contains a discardable file is conceptually organized as shown in the file system structure of FIG. The file system is similar in structure to the standard FAT32 file system found on SD-HC (and corresponding high capacity μSD) cards. In the implementation of the discardable file HD, the discardable file is stored in the shadow FAT.

Shadow FAT
The first two FAT tables allocate discardable clusters using only 0xpFFFFFFF (EOF) or 0xp00000000 (unassigned) values that indicate the priority of the file but not its actual chain. If the most significant nibble is non-zero, a third FAT table is considered to determine the actual cluster chain sequence. Unlike the first two FAT tables, the Discardable FAT (DFAT) table can contain a cluster chain longer than 4 GB.

A directory entry for a directory table discardable file has the following elements: Elements that can be encrypted are represented as blobs (binary large objects) in an encrypted variant of the system, and they can be combined into a single blob. These fields are described here.

Large File Manager The Large File Manager (LFM) is a process handler that is implemented in smart caching HD to process files larger than 4GB. Conceptually, the LFM consists of a file parser and a set of predefined partitioning algorithms, as shown in FIG. The LFM can be implemented in a storage device if a host, or other smart caching component, is present on the storage device.

The file parser identifies the file (such as that used in the Linux file command) and uses a well-known method that considers the MIME type if it was stored in a discardable file directory entry. The type database is a simple table of file types and their corresponding split handlers that are incorporated in the LFM. Although the figure shows three split handlers, additional split handlers can be incorporated as needed. Usually, the split handler is
Verify the structure of the disposable file,
Calculate the total number of segments into which the file is split (this will usually be the size of the file divided by 4GB, but file format constraints may require additional files)
It has an interface for creating a header for each segment of the file and calculating the offset of each segment boundary.

The actual division of the file is done during conversion as described below.
Conversion Flow The conversion flow in smart caching HD is shown in FIG. Process 2400 begins with a call to convert () function by the application in step 2402. The convert () function permits the conversion process via a charging mechanism (as described in the smart caching application) at step 2404. If the conversion is not allowed at step 2406, a security exception results at step 2407. If the conversion is allowed in step 2406, the next step is to lock the file system in step 2408 so that other processes and device drivers do not modify it during the conversion process, and after the process is finished, Consider refresh. Thereafter, in steps 2410 and 2412, a cluster chain for the file to be converted is allocated in the FAT1 and FAT2 tables of the volume to detach the chain from the existing placeholder file located for dosfsck protection purposes, and if necessary Reorder the cluster chain. If the total length of the file is less than 4 GB in step 2414, a directory entry is created for the file in steps 2416, 2418, 2420, and 2422, the file system is unlocked and refreshed in step 2424, and convert () The flow ends in step 2426.

  If the total length of the file is greater than 4 GB, the process proceeds to step 2428. Files larger than 4 GB are typically HD media files, which can be divided into segments that are played sequentially. Those segments can be linked together during playback, providing a seamless playback experience. However, simply splitting the file into 4GB segments cuts the file at the center of the frame, or the metadata (such as the file header) that one or more of the segments needs to identify or play the file. You can lose. Thus, each segment begins with a metadata header generated by the LFM that is suitable for the format. Certain file types, such as documents or executable files, are not inherently segmented, and those files cannot be converted to smaller segments using this strategy. For such files, the large file manager can use a compression library such as ZIP and supports splitting while preserving the order of the files. The large file manager uses the flow shown in FIG. 25 when converting a file.

  The process 2500 for managing files longer than 4 GB begins at step 2502 with a return request by the application. In step 2504, the file header is read, and in step 2506, it is determined whether the file is of a known type. If the file is not of a known type, the process proceeds to step 2508 where the file is spanned into a number of files using a general method, and in step 2510, the spanned files are The conversion process continues.

  If the file is of a known type at step 2506, it is determined at step 2512 whether the file type supports spanning into multiple files. If the file type supports spanning multiple files, the file is spanned into multiple files using a method specific to the file type in step 2514 before proceeding to step 2510. However, if the file type does not support spanning multiple files, the file is spanned into multiple files using the general method at step 2508 before proceeding to step 2510.

As an example of a method specific to the file type, FIG. 26 depicts a schematic diagram of an open source Matroska (mkv) container file format commonly used in high definition video streams. A Matroska file usually consists of a file header followed by a segment (Extensible Binary Meta-Language (EBML) header) and ends with a tag. These files can be longer than 4 GB. Although such large files cannot be effectively represented in the FAT32 file system, to divide these files, the segment itself is divided into multiple files, each of which has its own EBML header and segment header. There are fields in the segment header that are useful for linking files that have been split:

  The process of splitting the Matroska file includes assigning and creating a new MKV file for each split segment, and adding an EBML header and a rewritten segment header for each segment.

  The large file manager incorporates support for various file types, such as Matroska, and in each case uses a unique split handler for each file type to make in-place splitting transparent for the file type. Run. In-place partitioning adds a cluster containing the new header information to the cluster chain as shown in FIG. 27, then adds a new directory entry for each file and the appropriate By dividing the cluster chain into a number of files by assigning FCNs at locations, this is done without moving the data in the files. (The cluster number immediately preceding the FCN in the chain indicates the EOF marker.) There are similar flows for other file types that are included in the large file manager. The large file manager automatically detects the file type and causes in-place splitting accordingly.

  The present application includes methods and systems for managing storage devices. In one implementation, a storage allocator residing on a host or storage device receives a request to store a file in a storage area of the storage device. The storage allocator marks the file as discardable in the file system structure associated with the storage device and updates the primary file allocation table (“FAT”) to associate the cluster chain assigned to the file with the file. The storage allocator can also update the discardable FAT or database to represent the physical location of the file, or generate one or more location files that store the physical location of the file. The storage allocator then manages the storage area device based on the FAT and a discardable FAT that indicates the physical location of the file, a database, or one or more location files.

  Numerous methods and systems are disclosed as described above and can be implemented in numerous ways. Although only a few examples of implementation combinations are provided below, they are not limiting and additional features and combinations are possible.

  In one implementation, a first method for managing a storage device is the first method in a storage area of a storage device that includes a primary FAT and a discardable FAT at a host to which the storage device is operatively coupled. Receiving a request to store one file and marking the first file as discardable, wherein the first file is marked in the file system structure associated with the storage device To associate the cluster chain assigned to the first file with the first file, to cause the storage device to update the primary FAT, and to represent the physical location of the first file in the storage device, Causing the storage device to update the discardable FAT and storing the storage device in accordance with the discardable FAT; And to manage, it can contain.

  In this manner, the cluster chain masks at least the physical location of the first file, and the primary FAT cluster chain may point to a location in the discardable FAT. Storage area management of storage devices in accordance with the Discardable FAT is a recovery of storage usage safety margin by selectively removing one or more files that are marked as Discardable, all files that are marked as Discardable Any one or a combination of freeing storage by removing or remapping the cluster of the first file to a lower performance storage module.

  The first method may also include allowing an attribute associated with the first file to prevent the host operating system from accessing the first file. Alternatively, the first method is to receive a request to store the second file in a storage area of the storage device and to mark the second file as discardable, and to mark the second file Is performed in the file system structure associated with the storage device and causes the storage device to update the primary FAT to associate the cluster chain associated with the first file and the second file with the second file. And causing the storage device to update the discardable FAT to represent the physical location of the second file. The cluster chain can mask the physical location of the first file and the second file.

  The first method described above is to receive a request to store a second file in a storage area of a storage device and to mark the second file as discardable, and to mark the second file Is performed in the file system structure associated with the storage device and causes the storage device to update the primary FAT to associate the second cluster chain assigned to the second file with the second file And causing the storage device to update the discardable FAT to represent the physical location of the second file.

  The first method is instead to mark the first file as a non-disposable file, wherein marking the first file is performed in a file system structure associated with the storage device; Causing the storage device to update the primary FAT to represent the physical location of the first file; and causing the storage device to update the discardable FAT to remove the physical location of the first file. , Can be included. This alternative of the first method identifies the value of the conversion lock identifier associated with the first file to determine whether the first file can be converted from a discardable file to a non-disposable file. The first file is marked as a non-disposable file after the determination of the value of the conversion lock identifier associated with the first file indicates that the first file is not locked. Is done.

  In another alternative of the first method, the value of the conversion lock identifier associated with the first file to determine whether the first file can be converted from a discardable file to a non-discardable file. Identifying and marking the first file as non-disposable after the determination of the value of the conversion lock identifier associated with the first file indicates that the first file is locked. Further prohibiting may be included. The first method instead identifies the file ID associated with the user ID and the preview file associated with the first file, and the first file based on the identified file permission. Managing access to a preview file associated with the. The user ID may be a shared user ID.

  In the first method, marking the first file as discardable can include assigning a discard priority level to the first file. Further, assigning a discard priority level to the first file sets the corresponding value to the m most significant bits in the primary FAT entry corresponding to the first file, or sets the corresponding value to the first It may include at least one of setting in a data field in a file system entry corresponding to a file. The discard priority level is the expected usage of the first file, the expected revenue associated with the usage of the first file, the file type of the first file, the size of the first file, the first in the storage device The first file can be assigned according to any one of the location of the file and the age of the first file.

  In another implementation, a second method of managing a storage device is a storage device storage region that includes a primary FAT and a discardable FAT in a storage device operably coupled to a host. Receiving a request to store the first file in the file system and marking the first file as discardable, wherein marking the first file is performed in a file system structure associated with the storage device. To update the primary FAT to associate the cluster chain assigned to the first file with the first file, and to represent the physical location of the first file in the storage device Updating the possible FAT, managing the storage area of the storage device according to the discardable FAT, It can be included. The cluster chain can mask at least the physical location of the first file. The second method can further include allowing an attribute associated with the first file to prevent the host operating system from accessing the first file. The primary FAT cluster chain may point to a location in the discardable FAT.

  In one variation, the second method can receive a request to store the second file in a storage area of the storage device and can discard the second file in the file system structure associated with the storage device. Marking, updating the primary FAT to associate the cluster chain with which the cluster chain is associated with the first file and the second file with the second file, and representing the physical location of the second file And updating the discardable FAT. In this variation, the cluster chain can mask the physical location of the first file and the second file.

  In another implementation, the second method receives a request to store the second file in a storage area of the storage device, and stores the second file in the file system structure associated with the storage device. Marking discardable, updating the primary FAT to associate the second cluster chain assigned to the second file with the second file, and representing the physical location of the second file And updating the discardable FAT.

  Instead, the second method uses the primary FAT to mark the first file as a non-disposable file in the file system structure associated with the storage device and to represent the physical location of the first file. And updating the discardable FAT to remove the physical location of the first file. This alternative of the second method identifies the value of the conversion lock identifier associated with the first file to determine whether the first file can be converted from a discardable file to a non-discardable file. The first file is marked as a non-disposable file after the determination of the value of the conversion lock identifier associated with the first file indicates that the first file is not locked. Is done.

  Another version of the second method uses the value of the conversion lock identifier associated with the first file to determine whether the first file can be converted from a discardable file to a non-discardable file. Prohibiting marking the first file as non-disposable after identifying and determining the value of the conversion lock associated with the first file indicates that the first file is locked And further. The second further one version identifies the file permissions associated with the user ID and the preview file associated with the first file, and the first based on the identified file permissions. Managing access to a preview file associated with the file. The user ID may be a shared user ID.

  In the second method, marking the first file as discardable can include assigning a discard priority level to the first file. Assigning a discard priority level to the first file sets the corresponding value to the m most significant bits in the primary FAT entry corresponding to the first file, or sets the corresponding value to the first It may include at least one of setting in a data field in the file system entry corresponding to the file. Alternatively, the discard priority level may be the expected usage of the first file, the expected revenue associated with the usage of the first file, the file type of the first file, the size of the first file, the number in the storage device. The first file can be assigned according to any one of the location of the file and the age of the first file.

  In the second method, managing the storage area of the storage device in accordance with the discardable FAT recovers the storage usage safety margin by selectively removing one or more files that are marked as discardable. One or a combination of either freeing storage by removing all files marked as, or remapping the cluster of the first file to a lower performance storage module .

  A storage allocator for managing a storage device is associated with a storage device and a communication interface for interfacing with the storage device host, a storage unit for storing a file system associated with the storage device, and the storage device. For receiving a request to store a first file in a storage area of a storage device including a primary FAT and a discardable FAT; The first file is marked as discardable in the file system structure associated with the storage device and the storage device is primary in order to associate the cluster chain assigned to the first file with the first file. Update FAT and store memory To represent the physical location of the first file in the discardable FAT is updated in the storage device, it is configured to manage the storage area of the storage device according discardable FAT. The cluster chain masks the physical location of the first file. The cluster chain of the first FAT can point to a position in the second FAT.

  Alternatively, the processor receives a request to store the second file in the storage area of the storage device, marks the second file in the file system structure associated with the storage device as discardable, the first file and the first file Causing the storage device to update the primary FAT to associate the cluster chain associated with the second file with the second file, and causing the storage device to update the second FAT to represent the physical location of the second file. The discardable cluster chain masks the physical location of the first file and the second file.

  In another variation of the storage allocator described above, the processor receives a request to store a second file in the storage area of the storage device and discards the second file in the file system structure associated with the storage device. Mark as possible and have the storage device update the primary FAT to associate the second cluster chain assigned to the second file with the second file and store it to represent the physical location of the second file It can be further configured to cause the device to update the discardable FAT. This variation of the storage allocator marks the first FAT in the storage device to mark the first file as a non-disposable file in the file system structure associated with the storage device and represents the physical location of the first file. The processor can be further configured to update and cause the storage device to update the discardable FAT to remove the physical location of the first file. Further, the processor is further configured to identify a value of the conversion lock identifier associated with the first file to determine whether the first file can be converted from a discardable file to a non-discardable file. After the determination of the value of the conversion lock identifier associated with the first file indicates that the first file is not locked, the first file is marked as a non-disposable file.

  In other implementations, the storage allocator identifies a translation lock identifier value associated with the first file to determine whether the first file can be converted from a discardable file to a non-discardable file. And marking the first file as non-disposable after the determination of the value of the conversion lock identifier associated with the first file indicates that the first file is locked. The processor can be further configured. Instead, the storage allocator processor identifies the file permissions associated with the user ID and the preview file associated with the first file and associates with the first file based on the identified file permissions. Can be further configured to manage access to the preview file being viewed.

  A storage system having a communication interface and a storage allocator for managing a file system associated with the storage device is also disclosed. The storage allocator can include a processor for managing the storage of one or more files in the storage area of the storage device, and the processor is configured in the same manner as the storage allocator described above. In various implementations, the storage allocator of the storage system can be embedded in the host or storage device. The storage system receives a request to store the first file based on one or more write requests associated with the first file received via the communication interface to receive the request via the communication interface. The processor may also be configured to derive.

  A third method for managing a storage device is also disclosed, wherein the third method receives a request to store a first file in a storage area of the storage device at a host to which the storage device is operatively coupled. To mark the first file in the file system structure associated with the storage device as discardable and to associate the cluster chain assigned to the first file with the first file to the FAT Updating the database, updating the database to represent the physical location of the first file in the storage device, and managing the storage area of the storage device according to the FAT and the database.

  A fourth method for managing a storage device can receive a request to store a first file in a storage area of the storage device and discard the first file in a storage device operably coupled to a host The first file is marked in the file system structure associated with the storage device, and the cluster chain assigned to the first file is defined as the first file. Updating the FAT for association, updating the database to represent the physical location of the first file in the storage device, and managing the storage area of the storage device according to the FAT and the database.

  The fifth method for managing the storage device includes steps associated with those of the fourth method described above from the perspective of the host rather than the storage device. More specifically, a fifth method is associated with receiving a request to store a first file in a storage area of a storage device at a host to which the storage device is operatively coupled, and associated with the storage device. Marking the first file in the file system structure as being discardable, causing the storage device to update the FAT to associate the cluster chain assigned to the first file with the first file, and storing Updating the location file to represent the physical location of the first file in the device and managing the storage area of the storage device according to the FAT and the location file. The location file may be a file such as a text file or a binary file.

  A sixth method for managing a storage device is associated with receiving a request to store a first file in a storage area of the storage device at a host to which the storage device is operatively coupled, and associated with the storage device. Marking the first file as discardable in the file system structure; causing the storage device to update the FAT to associate the cluster chain assigned to the first file with the first file; Scramble the order of two or more clusters of the cluster chain associated with the first file, and a first range file comprising at least one cluster of the cluster chain associated with the first file. Creating in the FAT and storage device according to the FAT and the first range file Including and managing the 憶領 region, a.

  A sixth method includes receiving a request to store a second file in a storage area of a storage device, marking the second file as disposable in a file system structure associated with the storage device, Two of the cluster chain associated with the second file in the FAT and the storage device updates the FAT to associate the cluster chain associated with the first file and the second file with the second file. Scrambling the order of the above clusters. Moreover, the sixth method can further include updating the first range file in the FAT to include at least one cluster in the cluster chain associated with the second file.

  In one variation of the sixth method, the method receives a request to store a second file in a storage area of a storage device, and stores the second file in a file system structure associated with the storage device. Marking the discardable, causing the storage device to update the FAT to associate the second cluster chain assigned to the second file with the second file, and the second file in the FAT; Scrambling the order of two or more clusters in the associated second cluster chain; and a second range file in the FAT that includes at least one cluster in the cluster chain associated with the second file. Creating the storage device according to the FAT and the first range file. Managing the band includes managing FAT, the storage area of the storage device according to the first range file and the second range file.

  In another variation of the sixth method, the method includes a second in the FAT having at least one cluster in the cluster chain associated with the first file that does not include the first range file. Creating a range file, and managing the storage area of the storage device according to the FAT and the first range file may include storing the storage device according to the FAT, the first range file, and the second range file. Includes managing areas.

  A seventh method for managing a storage device includes steps associated with those of the sixth method described above from the perspective of the storage device rather than the host. More specifically, according to the seventh method, in the storage device coupled to the host, a request for storing the first file in the storage area of the storage device can be received, and the first file can be discarded. Marking the first file is performed in a file system structure associated with the storage device and associating the cluster chain assigned to the first file with the first file For updating the FAT, scrambling the order of two or more clusters in the cluster chain associated with the first file in the FAT, and for the cluster chain associated with the first file. Creating a first range file in the FAT that includes at least one cluster; It includes managing the storage area of the storage device according to the first range file, a. This modification of the seventh method is similar to that of the sixth method described above.

  In an eighth method, the method of managing an operation associated with a discardable file at a host to which the storage device is operably coupled is associating an owner user ID with the discardable file, wherein the discardable file For files that are marked as discardable in the file system structure associated with the storage device, and for additional user IDs associated with the discardable file in the application associated with the owner user ID Defining a set of permissions, receiving a request to perform an operation associated with the disposable file from an application associated with the additional user ID, and adding additional users based on the set of permissions Associated with the ID Includes determining whether the application can perform the operation, based on the determination, and to manage operations associated with disposable file, a.

  In this eighth method variant, the application associated with the owner user ID can download the discardable file to the storage device. Alternatively, the operation associated with the discardable file can include modifying an attribute associated with the discardable file. In another variation of the eighth method, the method can further include reading an attribute associated with the discardable file. The attribute may be at least one of a conversion lock identifier, a time stamp, a consumption intention universal resource indicator, or a priority level. In yet another variation of the eighth method, the operation is associated with reading a discardable file, writing to a discardable file, writing preview data associated with a discardable file, or associated with a discardable file. Reading out the preview data. The discardable file can include preview data or can be separate from the preview data in different implementations.

  The additional user ID of the eighth method can be a shared user ID associated with multiple users. Alternatively, the additional user ID of the eighth method can be a shared user ID associated with multiple applications. In one additional variation of the eighth method, managing an operation associated with the discardable file based on the determination associates the application associated with the additional user ID with the discardable file. Forbidden to perform the operation that is being performed. In another additional variation, managing an operation associated with the discardable file based on the determination includes an operation associated with the discardable file by an application associated with the additional user ID. Including allowing it to run.

  Also contemplated are storage systems having a communication interface and a storage allocator for managing a file system associated with the storage device. The storage allocator can include a processor for managing operations associated with a discardable file stored in the storage device, the processor including an owner user ID and a file system structure associated with the storage device. Define a set of permissions for an additional user ID associated with the discardable file in an application associated with the discardable file, including the file marked as disposable in A request to perform an operation associated with the disposable file is received from the application associated with the additional user ID via the communication interface and is associated with the additional user ID based on a set of permissions. Application determines whether the operation can be performed, based on the determination, is configured to manage operations associated with the discardable file. In order to manage operations associated with the discardable file, the processor may be configured to allow an application associated with the additional user ID to read preview data associated with the discardable file. . The additional user ID may be a shared user ID associated with multiple users or a shared user ID associated with multiple applications.

  A ninth method for managing storage devices includes storing preview data in a storage device at a host to which the storage device is operatively coupled, and preview data in a file system structure associated with the storage device. To preview data and discardable files so that they can be associated with a discardable file that is marked as discardable and the application is allowed to access the preview data but is not allowed to access the discardable file Managing access. The discardable file may be preview data that is separate from the preview data. In an alternative implementation of the ninth method, the discardable file is a movie and the preview data can be a movie trailer associated with the movie, and the discardable file is a television program and the preview data Can be part of a television program, the discardable file is music data and the preview data can be part of music data, or the discardable file is a program and the preview data is a program Can be a demo version of.

  One alternative implementation of the ninth method manages access to the preview data and the discardable file so that the application is allowed to access the preview data but is not allowed to access the discardable file. Preview data and discard so that the application is allowed access to the preview data during the period prior to the release date associated with the discardable file, but is not allowed to access the discardable file. Can include managing access to possible files.

Described before download management, further added to the method of managing the referred data to as smart caching and smart caching HD, smart caching technique for managing the downloading of discardable file to the storage area of the storage device is provided. In general, in some implementations, the download manager, which can be part of a storage allocator, determines the type of network that can be used to download the discardable file to the storage device, the power requirements that can be used for the storage device, Discardable to the storage area of the storage device based on download conditions such as the duration associated with the request to download the discardable file to the storage device and / or the amount of available storage associated with the storage device It can be determined whether to delay the download of the file.

  For example, the download manager may determine that the download of the discardable file is delayed until a wireless fidelity (WiFi) network and / or cellular network is available to download the discardable file. Similarly, the download manager can determine that the download of the discardable file is not delayed while the storage device is coupled to a power source or the power level of the battery associated with the storage device is above a predetermined level. However, the download manager may delay the download of the discardable file while the battery associated with the storage device is being charged and / or the power level of the battery associated with the storage device is below a predetermined level. Can be determined. In addition, the download manager decides to delay the download of disposable files requested during business hours when network congestion may be severe until late at night, such as after 8pm when the network may not be congested. Alternatively, the download manager may decide to delay the download of the discardable file requested on weekdays until the weekend. The download manager can further delay the download of the discardable file until the amount of storage available on the storage device prior to storing the discardable file in the storage area of the storage device is above a predetermined level.

  FIG. 28 is a flowchart of a method for managing download of a discardable file to a storage area of a storage device. At step 2802, a request to store the file in a storage area of the storage device is received and the file is a discardable file and is associated with data in a data structure associated with the storage device. In some implementations, the data structure can include a file system structure. At step 2804, the file is marked as a “disposable file”. In some implementations, the file system structure of the data structure is marked to indicate that the file is a discardable file. In other implementations, the file itself is marked to indicate that the file is a discardable file.

  At step 2806, the download manager, which in some implementations may be part of the storage allocator, determines the download conditions associated with the request to store the discardable file in the storage area of the storage device. For example, the download manager can store the type of network that can be used to download the discardable file to the storage device, the power condition that the storage device can use when downloading the discardable file to the storage device, and the storage device The time associated with the request to store in the storage area can be determined and / or the amount of storage space available on the storage device can be determined.

  In step 2808, the download manager determines whether to delay the download of the discardable file to the storage device based on the determined download condition, and in step 2810, the download manager determines the discardable file to the storage device. Managing the download of the discardable file to the storage device based on the determination of whether to delay the download of the file. At step 2810, the download manager can delay the download of the discardable file to the storage device until the parameters associated with the download conditions are met. For example, the download manager can delay the download of the discardable file until the WiFi network and / or cellular network is available to download the discardable file to the storage device, and the download manager can power the storage device And / or the download manager may delay the discardable file until the power level of the battery associated with or associated with the storage device is above a predetermined level, and / or the download manager may store the discardable file in the storage device The download of the discardable file can be delayed until the amount of storage available in the storage device before storing in the storage area becomes higher than a predetermined level.

  At step 2812, the storage allocator, which may include a download manager, manages storage in the storage area of the storage of the downloaded discardable file based on the marking that the file is a discardable file, as previously described. To do.

  In some implementations, one or more processors may be configured to perform the operations described above with respect to FIG. 28 based on instructions stored in memory, such as a computer-readable non-transitory storage medium. You should understand that. The one or more processors can be located on a host, a storage device, or a combination of both.

  The methods disclosed herein for marking files and assigning discard levels to them in the associated file system can have many useful applications, one of which is for user files It should be noted that the storage usage safety margin is restored to ensure sufficient storage space. For example, the discard level assigned to a file can be used to remap the file cluster to a lower performance flash module or to clear the cluster on demand.

  Articles are used herein to refer to one or more (ie, at least one) of an article's grammatical objects, depending on the context. By way of example, depending on the context, “element” can mean one element or more than one element. The term "including" is used herein to mean the phrase "including but not limited to ..." and is used interchangeably. The terms “or” and “and” are used to mean the terms “and / or” and are used interchangeably unless the context clearly indicates otherwise. . The term "... etc." Is used herein to mean the phrase "... etc. (But not limited to ...)" and this Used interchangeably with phrase.

  It will be appreciated by those skilled in the art that exemplary embodiments of the invention are thus described and modifications of the disclosed embodiments are within the scope of the invention. Thus, alternative embodiments can include more modules, fewer modules, and / or functionally equivalent modules. Disclosures herein include SD-driven flash memory cards, flash storage devices, non-flash storage devices, “disk-on-key” devices with universal serial bus (“USB”) interfaces, USB flash drives (“UFD”), multimedia It is associated with various types of mass storage devices such as cards (“MMC”), secure digital (“SD”), mini-SD (miniSD), and micro-SD (microSD). Accordingly, the scope of the appended claims is not limited by the disclosure herein. Accordingly, the foregoing detailed description is to be regarded as illustrative instead of limiting, and it is the appended claims, including all equivalents, that are intended to define the spirit and scope of this invention It is intended.

Claims (30)

A method for managing a storage device, comprising:
On the host to which the storage device is operably coupled:
Receiving a request from a content publisher to store the file in the storage device that determines that the file is disposable;
Marking the file in the file system of the storage device as a discardable file;
The file system has a primary file allocation table (FAT) and a discardable FAT ;
Marking the file as a discardable file comprises:
Updating the primary FAT to associate the cluster chain assigned to the file with the file , the cluster chain at least masking the physical location of the storage device associated with the file;
Updating the discardable FAT to associate the physical location of the storage device with the file;
Concealing the file in the file system of the storage device to mask the file from a user, wherein the discardable file includes unsolicited content not requested by the user;
Determining a download condition associated with a request to store the discardable file in the storage device;
Determining whether to delay the download of the discardable file to the storage device based on the determined download condition and the marking that the file is a discardable file;
Managing the download of the discardable file to the storage device based on determining whether to delay the download of the discardable file to the storage device. The method of claim 1, wherein
Managing the discardable file download includes delaying the discardable file download to the storage device until a parameter associated with the download condition is satisfied. The method of claim 1, wherein
Determining a download condition associated with a request to store the discardable file on the storage device includes determining a type of network that can be utilized to download the discardable file to the storage device. Method. The method of claim 3, wherein
Determining the type of network that can be utilized to download the discardable file to the storage device determines whether a wireless fidelity (WiFi) network can be utilized to download the discardable file to the storage device. Including determining. The method of claim 3, wherein
Determining the type of network that can be utilized to download the discardable file to the storage device determines whether a cellular network can be utilized to download the discardable file to the storage device. A method involving that. The method of claim 1, wherein
Determining a download condition associated with a request to store the discardable file in the storage device determines a power condition that the storage device can use when downloading the discardable file to the storage device A method involving that. The method of claim 6 wherein:
The method of determining a power condition that the storage device can utilize when downloading the discardable file to the storage device includes determining that the storage device is coupled to a power source. The method of claim 6 wherein:
The method of determining a power condition that the storage device can utilize when downloading the discardable file to the storage device includes determining that a battery associated with the storage device is being charged. The method of claim 6 wherein:
Determining a power condition that the storage device can use when downloading the discardable file to the storage device determines that a power level of a battery associated with the storage device is higher than a predetermined level Including methods. The method of claim 1, wherein
Determining a download condition associated with a request to store the discardable file on the storage device includes determining a time associated with a request to store the discardable file on the storage device. . The method of claim 1, wherein
Determining a download condition associated with a request to store the discardable file in the storage device is based on the amount of storage available in the storage device prior to storing the discardable file in the storage device. Determining that it is higher than a predetermined level. The method of claim 1, wherein
The method of marking the file as a discardable file further comprises marking the file itself to indicate that the file is a discardable file. The method of claim 1, wherein
The step of marking the file as a discardable file further comprises assigning a discard priority level to the file. The method of claim 1, wherein
The primary FAT is included in a primary file system architecture;
The discardable FAT is included in a discardable file system architecture . The method of claim 1, wherein
A method further comprising managing storage of a downloaded discardable file in the storage device based on a marking that the file is a discardable file. A storage system,
A host in communication with a non-volatile memory including a file system having a primary file allocation table (FAT) and a discardable FAT ;
A processor on the host for managing storage of one or more files in the non-volatile memory;
The processor is
Receiving a request from a content publisher to store the file in the storage system that determines that the file is disposable;
Configured to mark the file as a discardable file;
In order to mark the file as a discardable file, the processor
Marking the file as discardable, wherein marking the file is performed in the file system associated with the storage system;
Updating the primary FAT to associate the cluster chain assigned to the file with the file, the cluster chain at least masking the physical location of the storage system associated with the file;
Updating the discardable FAT to associate the physical location of the storage system with the file;
Hiding the file in the file system of the storage system to mask the file from a user, the discardable file including unsolicited content not requested by the user;
Determining download conditions associated with a request to store the discardable file in the storage system;
Determining whether to delay the download of the discardable file to the storage system based on the determined download condition and the marking that the file is a discardable file;
A storage system configured to manage the download of the discardable file to the storage system based on a determination whether to delay the download of the discardable file to the storage system. The storage system of claim 16.
To manage the download of the discardable file, the processor is further configured to delay the download of the discardable file to the storage system until a parameter associated with the download condition is satisfied. system. The storage system of claim 16.
In order to determine a download condition associated with a request to store the discardable file on the storage system, the processor determines a type of network that can be utilized to download the discardable file to the storage system. A storage system further configured to. The storage system of claim 18.
To determine the type of network that can be used to download the discardable file to the storage system, the processor uses a wireless fidelity (WiFi) network to download the discardable file to the storage system. A storage system further configured to determine whether it can be performed. The storage system of claim 18.
In order to determine the type of network that can be used to download the discardable file to the storage system, the processor determines whether a cellular network can be used to download the discardable file to the storage system. A storage system further configured to determine whether. The storage system of claim 16.
In order to determine a download condition associated with a request to store the discardable file in the storage system, the processor may use power that the storage system may use when downloading the discardable file to the storage system. A storage system further configured to determine the condition. The storage system of claim 21, wherein
The processor is further configured to determine that the storage system is coupled to a power source to determine a power condition that the storage system can utilize when downloading the discardable file to the storage system. Storage system. The storage system of claim 21, wherein
To determine a power condition that the storage system can utilize when downloading the discardable file to the storage system, the processor determines that a battery associated with the storage system is charging. A storage system further configured. The storage system of claim 21, wherein
In order to determine a power condition that the storage system can utilize when downloading the discardable file to the storage system, the processor has a power level of a battery associated with the storage system higher than a predetermined level A storage system further configured to determine. The storage system of claim 16.
In order to determine a download condition associated with a request to store the discardable file in the storage system, the processor determines a time associated with a request to store the discardable file in the storage system. As further configured as a storage system. The storage system of claim 16.
In order to determine a download condition associated with a request to store the discardable file in the storage system, the processor is available in the storage system prior to storing the discardable file in the storage system. A storage system further configured to determine that the amount of storage is higher than a predetermined level. The storage system of claim 16.
In order to mark the file as a discardable file, the processor is further configured to mark the file itself to indicate that the file is a discardable file. The storage system of claim 16.
In order to mark the file as a discardable file, the processor is further configured to assign a discard priority level to the file.
The storage system of claim 16.
The primary FAT is included in a primary file system architecture;
The discardable FAT is a storage system included in a discardable file system architecture . The storage system of claim 16.
The storage system is further configured to manage storage of a downloaded discardable file in the non-volatile memory based on a marking that the file is a discardable file.

Images