Abstract:
A system and method are provided to manage storage space. The method comprises suspending a request responsive to detecting of a condition indicating a lack of a resource necessary to serve the request; applying a resource management procedure to increase availability of the resource; and, responsive to successful completion of the resource management procedure, serving the request.

Description:
RELATED APPLICATIONS 
   The present patent application claims the priority benefit of the filing date of Indian Application No. 713/che/2005 filed Jun. 10, 2005, which is incorporated herein by reference. 
   FIELD OF THE INVENTION 
   At least one embodiment of the present invention pertains to storage systems and, more particularly to method and system to automatically suspend write requests. 
   BACKGROUND 
   A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. Storage of information on the disk array is preferably implemented as one or more storage “volumes” of physical disks, defining an overall logical arrangement of disk space. 
   The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on the disks as a hierarchical structure of directories, files and blocks. A known type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block is retrieved (read) from disk into a memory of the storage system and “dirtied” (i.e., updated or modified) with new data, the data block is thereafter stored (written) to a new location on disk to optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL™) file system available from Network Appliance, Inc., Sunnyvale, Calif. 
   A storage system has a fixed amount of free space available to users. When all of the free space is consumed, additional writes fail even when the system is up and running, thereby causing user downtime. A write failure is always undesirable. NFS clients handle a failed write by returning an error. Where a hierarchical structure of blocks on the disks is exported to users as a named logical unit numbers (LUN), write failures are more catastrophic. For example, write failures may lead to corruption of application data or executables that are being stored on the LUN, host operating system crash, or file system corruption. 
   Existing systems do not attempt to utilize an automated mechanism to reclaim storage space prior to allowing a request (e.g., a write request) to fail. 
   SUMMARY 
   A system and method are provided to automatically suspend write requests. The method comprises suspending a request responsive to detecting of a condition indicating a lack of a resource necessary to serve the request; applying a resource management procedure to increase availability of the resource; and, responsive to successful completion of the resource management procedure, serving the request. 
   Other aspects of the invention will be apparent from the accompanying figures and from the detailed description that follows. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     One or more embodiments of the present invention are illustrated by way of example and not limited to the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
       FIG. 1  is a schematic block diagram of an environment including a storage system that may be used with one embodiment of the present invention; 
       FIG. 2  is a schematic block diagram of a storage operating system that may be used with one embodiment of the present invention; 
       FIG. 3  is a schematic block diagram of a space management component, according to one embodiment of the present invention; 
       FIG. 4  is a flow chart illustrating a method to automatically suspend write requests, according to one embodiment the present invention. 
       FIG. 5  is a flow chart illustrating a method to manage storage space utilizing an autodelete technique, according to one embodiment the present invention. 
       FIG. 6  is a flow chart illustrating a method to manage storage space utilizing an autosize technique, according to one embodiment the present invention. 
   

   DETAILED DESCRIPTION 
   A method and system are provided to automatically suspend write requests, such as write requests to centralized storage. A write request may be, for example, a file system write request or a SCSI block write request. In some embodiments, SCSI block write requests may be mapped by a storage operating system to file system write requests. 
   In one embodiment, a write request suspension enables the file system to free up storage space using various space management and space reclamation techniques. In a situation where space reclamation features did not start in advance (e.g., due to sudden bursts in traffic), the write suspension mechanism will trigger a space management procedure on an urgent basis in order to prevent the write request from failure. 
   This functionality may be utilized to enable the file system to attempt to serve writes that would have certainly failed. When the file system receives a write request, it first determines whether there is sufficient space on the target device and, if so, stores the write data in memory first (e.g., in a designated buffer cache). At this point the write request is “committed” and the initiator of the write request receives an indication of a successful write (a write acknowledgment). The actual transfer of write data to disk occurs subsequently to the committing of the write request, e.g., at predetermined time periods. Thus, before a file system commits any write request, it makes sure that there is enough space on the target disk to write the blocks designated by the request. If there is not sufficient free space in the volume, the write data is not stored in the buffer cache. Instead, the write request is rejected and an error message is provided to the user. 
   In one embodiment, such write requests (or simply writes) are not rejected if the volume has a space management policy enabled for the volume. Instead, the write is suspended in a queue and an appropriate space management procedure is triggered. Space management procedures may include, for example, a policy for automatically reclaiming space consumed by backup data or a policy for increasing available storage space by increasing the size of the target volume. 
   Once the space is made available, the writes are served and the client or host only sees a small and bounded delay on the writes acknowledgement. The writes might still fail if a space management procedure is not successful in providing available space within a maximum allowed suspend time. The maximum allowed suspend time may be provided by default or specified by the administrator (e.g., using a management console connected to the storage server). 
   Thus, in one embodiment, the file system is in effect slowing itself down in order to free up resources necessary to serve the clients and hosts. 
     FIG. 1  is a schematic block diagram of an environment  100  including a storage system  120  that may be advantageously used with one embodiment of the present invention. The storage system provides storage service relating to the organization of information on storage devices, such as disks  130  of a disk array  160 . The storage system  120  comprises a processor  122 , a memory  124 , a network adapter  126  and a storage adapter  128  interconnected by a system bus  125 . The storage system  120  also includes a storage operating system  200  that preferably implements a high-level module, such as a file system, to logically organize the information as a hierarchical structure of directories, files and special types of files called virtual disks (hereinafter “blocks”) on the disks. 
   In the illustrative embodiment, the memory  124  comprises storage locations that are addressable by the processor and adapters for storing software program code. A portion of the memory may be further organized as a “buffer cache”  170  for storing certain data structures. For example, in one embodiment, data associated with committed writes is stored in the buffer cache  170  prior to being written to the target persistent storage device. The processor and adapters may, in turn, comprise processing elements and/or logic circuitry configured to execute the software code and manipulate the data structures. Storage operating system  200 , portions of which are typically resident in memory and executed by the processing elements, functionally organizes the system  120  by, inter alia, invoking storage operations executed by the storage system. It will be apparent to those skilled in the art that other processing and memory means, including various computer readable media, may be used for storing and executing program instructions pertaining to the inventive technique described herein. 
   The network adapter  126  comprises the mechanical, electrical and signaling circuitry needed to connect the storage system  120  to a client  110  over a computer network  140 , which may comprise a point-to-point connection or a shared medium, such as a local area network. Illustratively, the computer network  140  may be embodied as an Ethernet network or a Fibre Channel (FC) network. The client  110  may communicate with the storage system over network  140  by exchanging discrete frames or packets of data according to pre-defined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). 
   The client  110  may be a general-purpose computer configured to execute applications  112 . Moreover, the client  110  may interact with the storage system  120  in accordance with a client/server model of information delivery. That is, the client may request the services of the storage system, and the system may return the results of the services requested by the client by exchanging packets  150  over the network  140 . The clients may issue packets including file-based access protocols, such as the Common Internet File System (CIFS) protocol or Network File System (NFS) protocol, over TCP/IP when accessing information in the form of files and directories. Alternatively, the client may issue packets including block-based access protocols, such as the Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI) and SCSI encapsulated over Fibre Channel (FCP), when accessing information in the form of blocks. 
   The storage adapter  128  cooperates with the storage operating system  200  executing on the system  120  to access information requested by a user (or client). The information may be stored on any type of attached array of writable storage device media such as video tape, optical, DVD, magnetic tape, bubble memory, electronic random access memory, micro-electro mechanical and any other similar media adapted to store information, including data and parity information. However, as illustratively described herein, the information is preferably stored on the disks  130 , such as HDD and/or DASD, of array  160 . The storage adapter includes input/output (I/O) interface circuitry that couples to the disks over an I/O interconnect arrangement, such as a conventional high-performance, FC serial link topology. 
   Storage of information on array  160  may be implemented as one or more storage “volumes” that comprise a collection of physical storage disks  130  cooperating to define an overall logical arrangement of (virtual block number) vbn space on the volume(s). Each logical volume is generally, although not necessarily, associated with its own file system. The disks within a logical volume/file system are typically organized as one or more groups, wherein each group may be operated as a RAID. Most RAID implementations, such as a RAID-4 level implementation, enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate storing of parity information with respect to the striped data. An illustrative example of a RAID implementation is a RAID-4 level implementation, although it will be understood that other types and levels of RAID implementations may be used in accordance with the inventive principles described herein. 
   To facilitate access to the disks  130 , the storage operating system  200  implements a write-anywhere file system that cooperates with virtualization modules to “virtualize” the storage space provided by disks  130 . The file system logically organizes the information as a hierarchical structure of named directories and files on the disks. Each “on-disk” file may be implemented as a set of disk blocks configured to store information, such as data, whereas the directory may be implemented as a specially formatted file in which names and links to other files and directories are stored. The virtualization modules allow the file system to further logically organize information as a hierarchical structure of blocks on the disks that are exported as named logical unit numbers (LUNs). 
     FIG. 2  is a schematic block diagram of the storage operating system  200  that may be advantageously used with one embodiment of the present invention. The storage operating system comprises a series of software layers organized to form an integrated network protocol stack or, more generally, a multi-protocol engine that provides data paths for clients to access information stored on the storage system using block and file access protocols. The protocol stack includes a media access layer  210  of network drivers (e.g., gigabit Ethernet drivers) that interfaces to network protocol layers, such as the IP layer  212  and its supporting transport mechanisms, the TCP layer  214  and the User Datagram Protocol (UDP) layer  216 . A file system protocol layer provides multi-protocol file access and, to that end, includes support for the Direct Access File System (DAFS) protocol  218 , the NFS protocol  220 , the CIFS protocol  222  and the Hypertext Transfer Protocol (HTTP) protocol  224 . A virtual interface (VI) layer  226  implements the VI architecture to provide direct access transport (DAT) capabilities, such as remote direct memory access (RDMA), as required by the DAFS protocol  218 . 
   An iSCSI driver layer  228  provides block protocol access over the TCP/IP network protocol layers, while a FC driver layer  230  receives and transmits block access requests and responses to and from the storage system. The FC and iSCSI drivers provide FC-specific and iSCSI-specific access control to the blocks and, thus, manage exports of LUNs to either iSCSI or FCP or, alternatively, to both iSCSI and FCP when accessing the blocks on the storage system. In addition, the storage operating system includes a storage module embodied as a RAID system  240  that manages the storage and retrieval of information to and from the volumes/disks in accordance with I/O operations, and a disk driver system  250  that implements a disk access protocol such as, e.g., the SCSI protocol. 
   Bridging the disk software layers with the integrated network protocol stack layers is a virtualization system that is implemented by a file system  280  interacting with virtualization modules illustratively embodied as, e.g., vdisk module  290  and SCSI target module  270 . The vdisk module  290  is layered on the file system  280  to enable access by administrative interfaces, such as a user interface (UI)  275 , in response to a user (system administrator) issuing commands to the storage system. The SCSI target module  270  is disposed to provide a translation layer of the virtualization system between the block (LUN) space and the file system space, where LUNs are represented as blocks. The UI  275  is disposed over the storage operating system in a manner that enables administrative or user access to the various layers and systems. 
   The file system is illustratively a message-based system that provides logical volume management capabilities for use in access to the information stored on the storage devices, such as disks. That is, in addition to providing file system semantics, the file system  280  provides functions normally associated with a volume manager. These functions include (i) aggregation of the disks, (ii) aggregation of storage bandwidth of the disks, and (iii) reliability guarantees, such as mirroring and/or parity (RAID). The file system  280  illustratively implements a write anywhere file system having an on-disk format representation that is block-based using, e.g., 4 kilobyte (kB) blocks and using index nodes (“inodes”) to identify files and file attributes (such as creation time, access permissions, size and block location). The file system uses files to store metadata describing the layout of its file system; these metadata files include, among others, an inode file. A file handle, i.e., an identifier that includes an inode number, is used to retrieve an inode from disk. 
   The write-anywhere file system has the capability to generate a snapshot of its active file system. An “active file system” is a file system to which data can be both written and read or, more generally, an active store that responds to both read and write I/O operations. It should be noted that “snapshot” is a trademark of Network Appliance, Inc. and is used for purposes of this patent to designate a persistent consistency point (CP) image. A persistent consistency point image (PCPI) is a space conservative, point-in-time read-only image of data accessible by name that provides a consistent image of that data (such as a storage system) at some previous time. More particularly, a PCPI is a point-in-time representation of a storage element, such as an active file system, file or database, stored on a storage device (e.g., on disk) or other persistent memory and having a name or other identifier that distinguishes it from other PCPIs taken at other points in time. In the case of the WAFL file system, a PCPI is always an active file system image that contains complete information about the file system, including all metadata. A PCPI can also include other information (metadata) about the active file system at the particular point in time for which the image is taken. The terms “PCPI” and “snapshot” may be used interchangeably through out this patent without derogation of Network Appliance&#39;s trademark rights. 
   The write-anywhere file system supports multiple snapshots that are generally created on a regular schedule. Each snapshot refers to a copy of the file system that diverges from the active file system over time as the active file system is modified. In the case of the WAFL file system, the active file system diverges from the snapshots since the snapshots stay in place as the active file system is written to new disk locations. Each snapshot is a restorable version of the storage element (e.g., the active file system) created at a predetermined point in time and, as noted, is “read-only” accessible and “space-conservative”. Space conservative denotes that common parts of the storage element in multiple snapshots share the same file system blocks. Only the differences among these various snapshots require extra storage blocks. 
   In one embodiment, the file system  280  includes a space management component  300 . The storage operating system  200  may be configured to allow a storage administrator to set up policy for automatically reclaiming space consumed by backup data (e.g., snapshots or some other type of backup images). An arrangement for automatically reclaiming space consumed by backup data may be termed an autodelete. In another embodiment, in a storage system that utilizes flexible volumes, an alternative or an additional policy may be set for automatically increasing available storage space by growing flexible volumes, which may be referred to as autosize. A flexible or “virtual” volume (vvol) is a volume that is contained within a file (i.e., a “container” file), where the vbn space of the virtual volume is sized to the container file. The size of the vvol is determined by the number of blocks it can use, rather than the size of the container file, which allows for flexible sizing of a flexible volume. Flexible (virtual) volumes are described in detail in U.S. patent application Ser. No. 10/836,817 titled, Extension of Write Anywhere File System Layout, filed Apr. 30, 2004, which is hereby incorporated by reference. 
   The space management component  300  may implement autosize and autodelete approaches to storage space management. An administrator may enable autodelete and autosize mechanisms utilizing associated commands that may be provided, for example, with command line interface (CLI) of a storage server or a management console connected to the storage server. 
   The space management component  300 , illustrated in  FIG. 3 , in one embodiment, includes a detector  302  to detect a condition that triggers a space management mechanism, an autodelete component  304 , and an autosize component  310 . The autodelete component  304  comprises, in one embodiment, a filter  306  to identify data that may be deleted by autodelete. The filter  306  may be configured, in one embodiment, to identify data that should not be deleted by autodelete. The filter  306  may also be responsible for determining the order in which data that is candidate for autodelete is examined. A remover  308  is responsible for deleting data marked for deletion by the filter  306 . 
   Returning to  FIG. 2 , the file system  280  further includes a request suspend component  285  that may be utilized to attempt to serve requests (e.g., write requests) that would have failed if this component was not present. The request suspend component  285  may take advantage of the space management component  300  by suspending write requests directed to a volume with insufficient free space until a space reclamation technique (e.g., automatic delete of backup data according to user-specified policy) or some other space management mechanism (e.g., increasing the size of a flexible volume) is attempted in order to provide enough space in the volume to serve the write request. 
     FIG. 4  is a flow chart illustrating a method  400  to automatically suspend write requests, according to one embodiment the present invention. When a write request arrives at the file system  280  (block  402 ), the file system determines whether enough free space is available in a volume associated with the request in order to write all the blocks to the disk. The write request is served if there is enough free space to commit the write. If however, there is insufficient space to serve the write (block  404 ), the file system determines whether there is a space management policy enabled on this volume (block  406 ). If the volume has a space management policy set, a preliminary examination of the space management feature is performed. For example, if the space management policy is a policy where selected backup data (e.g., snapshots) is automatically deleted according to rules specified by the administrator, the file system may first determine if there are any snapshots stored in the system. If the space management policy is a policy where the size of the target volume may be automatically increased, the file system may first determine if there is scope to grow the volume to the maximum size setting specified by the administrator. 
   In one embodiment, both autodelete and autogrow functionalities may be enabled on a particular volume. The administrator (broadly referred to as a user) may be permitted to set policy (user-specified policy) with regard to which resource management technique is to be attempted first. 
   If it is determined that it is possible to increase available free space, the file system makes sure that the write request has not already been waiting in the file system for any reasons (e.g., a space management procedure in progress or otherwise) for more than a user-specified period of time (block  408 ). If the request has been waiting for more than the permitted maximum period of time, the write request fails and a write failure message is sent to the requesting user. Also, any future write request suspensions are disabled. 
   If it is determined that the request has not been waiting for more than the permitted maximum period of time, the message is suspended on a suspend queue within the file system and a space management procedure is triggered (block  410 ). All messages in the suspend queue are woken up periodically (e.g., according to a user-specified or a default setting) so that the file system attempts to serve them (block  412 ). 
   In some embodiments, the file system suspend of requests functionality can be enhanced to find other resources in the storage server or in the file system, such as inodes, snapshot ids, or other resources that are causing user operations to fail. 
   In one embodiment, space management procedures comprise autodelete functionality and autosize functionality. Autodelete allows snapshots associated the volume to be automatically deleted. This approach may be useful when a volume is about to run out of available space and deleting snapshots can recover space for current writes to the volume. In one embodiment, autodelete is disabled by default so that an administrator needs to explicitly enable autodelete, e.g., utilizing an associated CLI command. The autodelete policy may be set on a per volume basis. 
   In one embodiment, the snapshots in a volume are deleted in accordance with a policy selected by a user (e.g., an administrator), e.g., utilizing a variety of CLI commands with associated options. An administrator may specify whether a particular snapshot or a snapshot in a particular condition is permitted to be deleted by autodelete. This option may be described as the level of commitment on the part of the user to allow autodelete. The higher the level of commitment is, the fewer conditions can prevent autodelete of particular snapshots. For example, an administrator may choose a setting where only those snapshots can be deleted by autodelete that are not locked by data protection or data backing utilities (a “try” level of commitment). Data protection utilities may include a utility that mirrors snapshots to different locations or transfers snapshots to another storage location such as a tape. Data backing utilities may include a cloning technique where a writable copy of a “parent” snapshot is generated. “Locking” refers to functionality provided, for example, with the mirroring and cloning tools to prevent users from deleting a “parent” snapshot or a snapshot that is in the process of being transferred to another destination. 
   A setting where only those snapshots that are not locked by data backing functionalities can be deleted may be referred to as a “disrupt” level of commitment. Thus, a “try” level of commitment is a lower level of commitment than the “disrupt” level. It will be noted that multiple levels of commitment may be implemented. In one embodiment, a user may allow deletion of snapshots that are locked by clones (a clone is a writable copy of a “parent” vvol) or restore processes (a “destroy level of commitment”). 
   Settings may be provided to specify the condition to start the automatic deletion of backup data such as snapshots. For example, a user may configure autodelete to be triggered when the volume itself is near full (e.g., a certain percent full), when the space reserved in the volumes is near full, or when the space reserved specifically for backup data is near full. A user may also specify a condition when snapshot autodelete should stop (once started). In one embodiment, the condition may be a percentage of free space achieved. 
   Another configurable setting may include the order in which snapshots should be deleted by autodelete. For example, autodelete may be configured to delete the most recent or the least recent snapshots first. 
   Autodelete may be configured to defer deletion of a particular kind of snapshot to the end. For example, a user may choose that user-created snapshots are deleted fist and that snapshots created by the snapshot scheduler are deleted last or vise versa. An order in which snapshots are deleted may also be set based on the prefix of the name string of a snapshot. 
     FIG. 5  is a flowchart of an illustrative method  500  to manage storage space utilizing autodelete functionality. Periodically (e.g., every 10 seconds) a kernel thread checks to see if there is a snap autodelete enabled on the volume (block  502 ). It then checks to see if the trigger condition is satisfied (block  504 ). The trigger condition is determined, in one embodiment, based on the trigger criteria specified by the administrator. For example, the trigger criteria set by the administrator may be “volume 90% full.” The trigger condition, on the other hand, may be set at a value below the trigger criteria specified by the administrator (e.g., at 98% of trigger criteria). If the trigger condition is satisfied, the method  500  verifies if there is already a process in progress that may be deleting some of the backup data such as a snapshot (block  506 ). In one embodiment, such process may be referred to as “snap delete” process. If there is a snap delete process in progress, the method  500  waits for that snap delete process to complete (block  508 ) before attempting to initiate an autodelete. If the target free space has not been achieved (block  510 ), the method  500  selects a snapshot that is appropriate for autodelete (block  512 ). The process scans the snapshots in the order specified by the user policy settings (e.g., starting with the most recent snapshots or with the least recent snapshots first). 
   In order to select an appropriate snapshot to be automatically deleted, the method  500  begins the scanning of all snapshots associated with the volume with the lowest commitment level in effect. For example, if a snapshot is found that satisfies the “try” criteria and is not designated as a snapshot for which autodelete should be deferred, the snapshot is marked for deletion and is then deleted (block  516 ). If no snapshot is found that satisfies the “try” criteria, the list of snapshots is scanned again, but this time ignoring defer criteria. If the search is still unsuccessful, the scan is performed with the next higher level of commitment allowed by the user. This process is continued until a snapshot suitable for deletion is found or the highest level of commitment designated by the user has been reached. 
   Autodelete may be repeated until the target free space has been achieved (block  516 ). 
   Another space management technique that may be implemented in one embodiment of the present invention is a mechanism that allows a flexible volume to automatically grow in size. This feature may be referred to as autosize. This approach may be useful when a volume is about to run out of available space but there is space available in the containing aggregate for the volume to grow. In one embodiment, autosize is disabled by default so that an administrator needs to explicitly enable autosize, e.g., utilizing an associated CLI command. The autosize policy may be set on a per volume basis. 
   A user (e.g., a system administrator) may specify the maximum size to which a flexible volume will be allowed to grow. When autosize operation is performed, the size of the volume is increased by the increment size specified with by the user. In one embodiment, a volume will not automatically grow if the current size of the volume is greater than or equal to the maximum size specified by the user. 
     FIG. 6  is a flowchart of an illustrative method  600  to manage storage space utilizing autosize functionality. Periodically (e.g., every 10 sec) a kernel thread checks to see if there is a snap autosize enabled on the volume (block  602 ). It then checks to see if the trigger condition (e.g., indicating that the volume is nearly full), is satisfied (block  604 ). If the trigger condition is satisfied, the processing logic verifies if there is scope to increase the size of the volume within the maximum size (block  606 ). The maximum size of the volume may be specified by the administrator (e.g., utilizing a management console). If there is not enough scope to increase the size of the volume (e.g., if the volume is already approaching the maximum size), a warning is returned to the user (block  608 ). 
   If there is enough scope, the method proceeds to block  610 , where it is determined whether the aggregate has enough space to allow the growth. If there is enough space in the aggregate to allow growth, the volume is grown (block  614 ), otherwise a warning message is returned to the user (block  616 ). 
   It will be noted that, in some embodiments, autosize feature may be used to reduce the size of the volume when there is excess free space. 
   In one embodiment, multiple space management techniques may be implemented (e.g., a user is permitted to have both autodelete and autosize functionalities set on a volume). A user may then also be permitted to specify which technique is to be used first when the volume is about to run out of space. A default preference may also be available. 
   It will be understood by those skilled in the art that the inventive technique described herein may apply to any type of special-purpose (e.g., file server, filer or multi-protocol storage appliance) or general-purpose computer, including a standalone computer or portion thereof, embodied as or including a storage system  120 . Moreover, the teachings of this invention can be adapted to a variety of storage system architectures including, but not limited to, a network-attached storage environment, a storage area network and disk assembly directly-attached to a client or host computer. The term “storage system” should therefore be taken broadly to include such arrangements in addition to any subsystems configured to perform a storage function and associated with other equipment or systems. 
   Thus, a method and system for automatic write request suspension have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. 
   It will be noted that the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” should also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall be taken to include “machine readable storage media” and “machine-readable signal media”. The term “machine-readable storage medium ” shall accordingly be taken to include, but not be limited to tangible storage media such as, solid-state memories, optical and magnetic media. The term “machine-readable signal medium” shall be taken to include intangible media, such as carrier wave signals.