Securing deallocated blocks in a file system

A computer-implemented method for operating a storage system comprising a file system for managing a data object in one or more storage blocks may be provided. The method comprising receiving from a file system manager a message indicating that the data objects is to be encrypted, determining, in response to the received message, a set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object, and rendering content of the unallocated storage blocks of the set unreadable.

BACKGROUND

The invention relates generally to a computer-implemented method for operating a storage system, and more specifically, to a computer-implemented method for operating a storage system comprising a file system for managing a data object in one or more storage blocks. The invention relates further to a storage control system for operating a storage system, and a computer program product.

More general, a file within a file system is comprised of data blocks. When the file is first created, its data are stored in data blocks on a storage device. During the life cycle data blocks may be re-allocated and unallocated, leaving original (old, deallocated) data blocks on the storage device and may be moved to other storage devices. Certain file system operations cause data blocks of a file to become deallocated, such as tiering from one storage tier to another, defragmentation that moves data blocks into consecutive entities or the use of certain applications such as text editors.

Defragmentation is used to ensure a fast access to files that have been spread across different blocks in a file system. Defragmentation is a process that reduces the amount of fragmentation by collocating data blocks of files. It does this by physically organizing the contents of the fragments into contiguous regions in an underlying storage device that is used to store files into. This requires copying data blocks of a file to new data blocks that are continuously arranged with other data blocks of the same file. Consequently, the old data blocks of the file are deallocated or unallocated.

SUMMARY

According to one aspect of the present invention, a computer-implemented method for operating a storage system comprising a file system for managing a data object in one or more storage blocks may be provided. The method may comprise receiving from a file system manager a message indicating that the data object is to be encrypted, determining, in response to the received message, a set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object, and rendering content of the unallocated storage blocks of the set unreadable.

According to another aspect of the present invention, a related storage control system for operating a storage system, the storage system comprising a file system for managing a data object in one or more storage blocks of the storage system may be provided. The storage control system may comprise a block tracking module adapted for receiving from a file system manager a message indicating that the data object is to be encrypted, wherein the block tracking module is adapted for determining, in response to the received message, a set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object and rendering content of the unallocated storage blocks of the set unreadable.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The aspects defined above, and further aspects of the present invention, are apparent from the examples of embodiments to be described hereinafter and are explained with reference to the examples of embodiments, but to which the invention is not limited.

Preferred embodiments of the invention will be described, by way of example only, and with reference to the following drawings.

DETAILED DESCRIPTION

The term ‘storage system’ may denote here a set of storage devices with a related storage management module. The storage devices may be implemented as storage drives which may be, e.g., solid state disks (SSD), flash disks, magnetic disk drives, an object storage, optical disks, and magnetic tapes. A drive can also be a volume provided by an intelligent disk system. Such volume may reside on a redundant array of independent disks (RAID).

The term ‘file system’ may control how data are stored and retrieved on a storage system. Without a file system, information placed in a storage medium would be one large body of data with no way to tell where one piece of information stops and the next begins. By separating the data into pieces (e.g., blocks) and assigning an identifier to each block, the information may easily be isolated and identified.

The term ‘data object’ may denote any type of file in a file system, but also a logical unit, a logical volume, or a block of data.

The term ‘storage block’ may denote a predefined number of bits or bytes managed as one unit on a storage device. Each storage block may be identifiable by a unique identifier for storage device.

The term ‘file system manager’ may denote a unit controlling the functioning of the file system, i.e., keeping track of different blocks in one or more storage system for different files.

The term ‘encrypted’ may denote that the content file has been made unreadable unless a decryption key is available. Symmetrical (i.e., using the same key for an encryption and decryption) or asymmetrical encryption (i.e., using different but related keys for the encryption and decryption) methods exist.

The term ‘unallocated storage block’ may denote a block having been part of a stored data object or file and may no longer be a direct and active portion of the file. However, due to a certain operation—in particular, defragmentation, migrating, encrypting, deleting, backing it up, and the like—the related blocks on the file system may only be marked as unused. However, the information may still be available unchanged. Thus, principally it is still readable. It may also be noted that the unallocated storage block may have undergone the process of de-allocation. Hence, such block may also be denoted as deallocated block.

The term ‘unreadable’ may denote that data—in particular unallocated blocks of a file—cannot be read anymore by the file system. The information is no longer available and access is definitely denied. This may be achieved by encrypting the data in the unallocated blocks, overwriting it, or permanently erasing it.

Protection of intellectual property, data privacy and other vertical market regulations guide enterprise organizations to ensure a proper protection of their data. The method of choice is often encryption. However, during an encryption and decryption process, unencrypted data fragments of the encrypted data may unintentionally continue to be available on a storage system.

More general, a file within a file system is comprised of data blocks. When the file is first created, its data are stored in data blocks on a storage device. During the life cycle data blocks may be re-allocated and unallocated, leaving original (old, deallocated) data blocks on the storage device and may be moved to other storage devices. This may represent a security exposure in case the file is encrypted later on. Because the original (old and unallocated) blocks of a file may not be encrypted and hence can be read by an attacker in clear text form. Certain file system operations cause data blocks of a file to become deallocated, such as tiering from one storage tier to another, defragmentation that moves data blocks into consecutive entities or the use of certain applications such as text editors. The resulting security challenges involved with these operations can be summarized as follows.

Defragmentation is used to ensure a fast access to files that have been spread across different blocks in a file system. Defragmentation is a process that reduces the amount of fragmentation by collocating data blocks of files. It does this by physically organizing the contents of the fragments into contiguous regions in an underlying storage device that is used to store files into. This requires copying data blocks of a file to new data blocks that are continuously arranged with other data blocks of the same file. Consequently, the old data blocks of the file are deallocated or unallocated. Problems occur if later-on the file is encrypted and unencrypted fragments as a result of the defragmentation process are still available and accessible.

Similar problems may occur in tiered file systems and during editing an encrypted file, whereby an unencrypted copy of the file may be created on the storage system. Also different copies of a file on different storage systems may lead to the same problem of leaving unencrypted copies behind after the file has been encrypted. The here proposed method and system address this problem and may ensure safe and secured deallocated blocks.

The proposed computer-implemented method for operating a storage system comprising a file system for managing a data object in one or more storage blocks may offer multiple advantages and technical effects:

Generally, an unallowed access to still unencrypted historic portions or fragments of files which have been encrypted will no longer be possible. The storage blocks of the file which has been encrypted are not only being made inaccessible but the information on these unallocated blocks is rendered unreadable by a permanent erase process and overwriting or an encryption. The encryption may optionally be carried out with the same key with which the target file is encrypted. Alternatively, a unique system encryption key may be used instead. The unique system encryption key may be changed periodically of according to predefined events in a particular manner.

In any case, a complete history of unallocated blocks of files in a tiered file system and also across file systems and/or storage systems may be generated. A new block tracking module managing a block tracking table may be instrumental in achieving this goal. By communicating with the file system manager or by integration into the system manager, a direct synchronization of activities of the file system manager and the block tracking module may be guaranteed.

According to one advantageous embodiment of the method, the storage system may be a tiered storage system comprising at least two storage tiers. Thereby, the determining the set of unallocated storage blocks may comprise identifying storage blocks of one storage tier of the at least two storage tiers previously allocated to the data object and migrated (i.e., moved from one storage tier to another) to the other storage tier of the at least two storage tiers currently allocated to the data object. This feature may ensure that the control over the unallocated storage may also work cross-tier in the storage system.

Thereby, the determination of the set of unallocated storage blocks may comprise whether such unallocated storage blocks for the storage object in question can be found in the block tracking table. If that is not the case, most probably, the block may have already been reused for another file. This feature is also valid for a non-tiered storage system, i.e., for a normal single disks drive computer or storage system.

Principally, there may be three different options for determining that an object has unallocated blocks. One would be that the block tracking module requests related information from the file system manager. The file system manager may always have data by default about whether a block is used or unused. Otherwise, it would not be possible to retrieve a file. Thus, no additional tracking would be required and no additional overhead of compared to the normal operation of the file system manager is required. The block tracking module would just request the related information from the file system manager which may respond with a logical “1” (“yes”) or “0” (“no”). Such a solution may rely on a fast communication between the block tracking module and the file system manager. However, if the block tracking module is integral part of the file system manager, such communication is not problematic.

Secondly, the block tracking module may be informed event-driven by a message from the file system manager to the block tracking when a previously used block is re-used to store data for a new data object. The block tracking module then removes this block from the block tracking table. Now the block tracking module may set a bit in the block tracking table relating to the block in question and trigger all required actions, i.e., ensuring that the now unallocated block may be rendered unreadable.

As a third option, the block tracking module may generate and store—e.g., in an extended version of the block tracking table—a checksum of the content of the block in question. Later, if there is an unallocated block, the block tracking module may compare the then present checksum with the one stored by the block tracking module. Also this may require an extension of the block tracking table.

According to another advantageous embodiment of the method, the rendering the content of the storage block of the set unreadable may comprise erasing—in particular, erasing it permanently—the content of the storage blocks of the set. In this case, the already available functions of the file system may be used. The erasing may be performed such that the unallocated block may become factually unreadable, e.g., by overwriting it with a random or predefined bit pattern. This goes beyond the usual marks in the block allocation table by the file management system that the relevant block has been deleted. Hence, and according to an alternative embodiment of the method, the rendering the content of the storage block of the set unreadable may comprise overwriting the content of the storage blocks of the set.

According to a possible embodiment of the method, the rendering the content of the storage blocks of the set may comprise encrypting the content of the storage blocks of the set. Thus, also in this case, the content, i.e., the data may become unreadable as long as the encryption key is not available. However, for normal read operations this is not the case; therefore, also in this case, the unallocated blocks cannot be read anymore by an unauthorized access.

According to an additional embodiment of the method, the data object may comprise at least one of a file, a logical unit, a logical volume, or a block of data. With this, all objects storable in a file system may be addressed.

According to an enhanced embodiment of the method, the storage system may be a tiered storage system comprising at least two storage tiers and/or a second storage system. Thereby, the determining the set of unallocated storage blocks may comprise identifying an unencrypted copy of the data object in another storage tier or a second storage system, and generating a message indicative of the unencrypted copy. This message may then be used to render the unallocated storage block belonging to the original storage object to be encrypted unreadable according to the same procedure, as explained above.

According to a further embodiment, the method may further comprise encrypting the unencrypted copy of the data object in another storage tier or another storage system, and rendering blocks in the other storage tier or other storage system relating to content of the unallocated storage blocks previously allocated to the unencrypted copy of the data object unreadable. If the second storage system may be used as a backup system, the proposed concept may also be extended to backup systems.

Also here, the determination whether the previously and potentially unallocated block have been repurposed as storage blocks for other files can be performed by referring to the block tracking table. In case they are re-used, the block tracking module may reset the entries for the unallocated blocks in the block tracking table.

As already discussed above, three options may to determine whether a block is unallocated: (i) the block tracking module requests related information from the file system manager; (ii) the block tracking module may be informed event-driven by a message form the file system manager to the block tracking module that a request for a file comprising the specific block in question; and (iii) the block tracking module may generate and store a checksum of the content of the block in question.

According to another advantageous embodiment, the method may also comprise operating a block tracking module in communicative contact with the file system manager. The block tracking module may be adapted for keeping track of all allocated blocks and unallocated blocks of all data objects of the storage system enabling a block allocation and block de-allocation—so that the related blocks becomes unallocated—history. This feature may render the here proposed concept also useful for other applications. It may, e.g., allow reconstructing earlier versions of a storage object in an easy way.

According to another further enhanced embodiment of the method, the block tracking module may also be adapted for keeping track of a data object, i.e., the related storage blocks—if the data object has been moved to another storage system. Hence, the history tracking data objects may also be used across storage systems.

In the following, a detailed description of the figures will be given. All instructions in the figures are schematic. Firstly, a block diagram of an embodiment of the inventive computer-implemented method for operating a storage system comprising a file system for managing a data object in one or more storage blocks is given. Afterwards, further embodiments, as well as embodiments of the storage control system for operating a storage system, will be described.

FIG.1shows a block diagram of a preferred embodiment of the computer-implemented method100for operating a storage system. The storage system comprises a file system for managing a data object in one or more storage blocks of the storage system, and the method100comprises receiving,102, from a file system manager a message indicating that the data object is to be encrypted. The message can be transmitted directly between the file system manager and a block tracking module, or indirectly via signal.

The method100comprises determining,104, in response to the received message, a set of unallocated storage blocks that were previously, i.e., before the encryption, allocated for storing at least a portion of the data object, and rendering,106, the content of the unallocated storage blocks of the set unreadable.

It should also be noted that the unallocated storage block can reside on the same storage tier, the same storage system and/or also on another storage system.

FIG.2shows a block diagram of an embodiment of a tiered file system202that manages a pool of storage drives. Storage drives are storage media, such as but not limited to, solid state disks (SSD), flash disks, magnetic disk drives, objects storage, optical disks as well as magnetic tapes. A drive can also be a volume provided by an intelligent disk system. Such volume may reside on a redundant array of independent disks (RAID). As shown inFIG.2, the architecture of the tiered file storage200includes a tiered file system202that is comprised of two storage pools206and208. Exemplary, the storage pool206comprises the drives210to216, and the storage pool208comprises the storage drives220to226. The number of storage drives per pool as well as the number of pools within the tiered file system is not limited to two storage pools, as shown.

When a file is stored in the tiered file system202, it is split into blocks that are stored on the storage drives of one of the pools206,208. For example, file 1 is stored in pool206, whereby blocks of the file are stored on the associated drives: a first block is stored on the storage drive210, a second block is stored on the storage drive212, a third block is stored on the storage drive214, a fourth block is stored on the storage drive216, and so on. The file system manager204keeps track which block is stored on which storage drive. This may also enhance the read speed because the blocks may be read at least partially in parallel.

The size of the blocks might be in accordance to the sector size of the storage drives, or it might be in accordance to a virtual volume block size. Virtual volumes are provided by intelligent disk systems that store the blocks on a Redundant Array of Independent Disk (RAID). A block might also be a data and parity block on a RAID.

In order to balance the capacity in the file system pools206and208, files can be migrated from one pool to another. For example: file 1 that was initially stored in pool206is migrated to pool208and its associated drives. Thereby, all the blocks of file 1 are copied from the storage drives of pool206to the storage drives of pool208. Afterwards, the blocks that where occupied, i.e., allocated, on pool206are deallocated or unallocated which means they can be re-used for other files. However, tiered file systems may not re-use unallocated blocks immediately. In fact it can take multiple days, weeks or month before deallocated or unallocated blocks are re-used. In the meantime, the content in the unallocated blocks may still be accessible, although not necessary directly via the file system. However, there remains a risk of unallowed access.

In order to avoid such a situation, the block tracking module230is in communicative contact with the file manager204to keep track of unallocated blocks which content has been encrypted as a new file. For that purpose, the block tracking module230manages a block tracking table232in order to keep track of unallocated blocks comprising at least parts of the file to be encrypted across the tiered file system.

The block tracking module230can be coupled to the file system manager204for the file system202, e.g., by means of an application programming interface (API). Through this coupling, the block tracking module obtains required information from the file system manager204, e.g., the blocks of a file stored on any of the pools206,208, or others. Furthermore, the file system manager204may inform the block tracking module230when the file is being migrated, encrypted, replicated, or backed up. The block tracking module230“follows” the file using the block tracking table, thereby enabling a complete history of storage locations and related storage blocks of the file.

FIG.3shows an exemplary structure of the block tracking table232. The first column comprises the file identifier; this can be the file name or a unique i-node number. The second column comprises the blocks, the file occupied on pool 1,206. The third column comprises the blocks of the file occupied on pool 2,208after the file has been moved. The fourth column comprises the blocks of the occupied file on pool N. The fifth column comprises the identifier of the file on a potential second storage system or a backup system. Each pool has a column for allocated and unallocated blocks of a file to track the trace of the file.

It may be noted that in case the file is moved to another storage system with another file system, an inter-file-management-system data exchange may be required. It also may require a cross-wise update of the block tracking tables in both file system for the relevant files. However, it cannot be guaranteed that all file systems are equipped with a block tracking module. If a file is moved from one storage system comprising the block tracking module to another with a different file management system and without a block tracking module, the attempt for a cross-synchronization of the block tracking table for the related files is simply not performed. Instead, a warning may be issued but the copy process from one storage system to the other continues without time delay.

FIG.4shows an exemplary structure400of the block tracking table for a file creation and a write process within a file system with one storage pool. It is assumed, that file 1 was newly created and has only the primary used blocks. File 2 was created in the past and has some fragmentation because of several right operations on the file in the path. The file 2 is old and has a longer trace as indicated by the allocated and unallocated blocks in the second and third column. E.g., file 2 is now stored in blocks 10, 11, 34, 56. In the past, portions of the file have also been stored in blocks 6, 7, 8, 9, 88, 89, 90, 100, 101, 203, 233, 332. Additionally, file 3 was recently defragmented and uses sequential blocks 20, 21, 22, 23 now. Also the unallocated blocks of file 3 are shown in the third column.

FIG.5shows an exemplary structure500of the block tracking table in the context of a migration process. When a file is migrated from a source storage pool to a destination storage pool, the block tracking module gets notified by the file system manager. Responsive to this, the block tracking module230determines the source storage pool and the destination storage pool for this file migration by communicating with the file system manager.

Furthermore, the block tracking module230determines whether the file is already encrypted. If the file is not encrypted, the block tracking module230inquires the file system manager to determine the blocks of the file on the source storage pool and updates the block tracking table, as shown inFIG.5.

E.g., the file with the identifier 100200300 (column 1) was started on blocks 1, 2, 3, 4 in pool 1 (column 2) in a non-encrypted form. Similarly, the file may further be migrated from pool 2 to pool N. In this case, the block tracking module230will determine and store the blocks where the file was stored in pool 2 and update the table (column 3).

If the file with the ID 100200300 is being encrypted, the block tracking module230gets notified by the file system manager. The file system manager can be extended to provide this functionality to notify the block tracking module230about the file encryption process. In response, the block tracking module230determines the identifier of the file, the current pool of the file, and the encryption key by communicating with the file system manager.

For example, the file identifier is 100200300, the current pool is pool 2 and the encryption key might be 0102030405060708090A0B0C. The block tracking module230now determines if the file has unallocated blocks in other pools by matching the file identifier in the block tracking table (column 1). For example, the file with ID 100200300 (row 2, column 1) has unallocated blocks in pool 1 (row 2, column 2).

If the file has unallocated blocks, then the block tracking module230inquires the file system manager which of the deallocated blocks have not been re-used yet. For example, the blocks 1, 2, 3 might not have been re-used on pool 1.

For all blocks that have not been re-used the block tracking module230encrypts these blocks with the key received by the file system manager. For example, blocks 1, 2, 3 in pool 1 are encrypted.

Using the block tracking table232, the block tracking module230further determines if the file has a backup identifier by inspecting column 5 (compareFIG.5). For example, the file with ID 100200300 has a backup identifier 223344 (row 2, column 5). If the file has been a backup ID, then the block tracking module encrypts the file in the backup server, or makes it otherwise unreadable.

FIG.6shows a block diagram of an embodiment of the storage control system600for operating a storage system comprising a file system for managing a data object in one or more storage blocks. The storage control system600comprises a block tracking module602adapted for receiving from a file system manager204(compareFIG.2) a message indicating that the data object is to be encrypted. Thereby, the block tracking module230(compareFIG.2) is adapted for determining, in response to the received message, a set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object, and rendering content of the unallocated storage blocks of the set unreadable. It should also be noted that the file system manager, the block tracking module230and a storage for tracking table232(compareFIG.2) can be implemented completely and hardware comprising communication channels between them.

It shall also be mentioned that the determination the set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object is supported by the block tracking module by referring to the block tracking table. It may well be possible that the blocks that were previously allocated for storing at least a portion of the data object have been allocated to new files. In that case unallocated blocks relating to the data object may not be found.

Embodiments of the invention may be implemented together with virtually any type of computer, regardless of the platform being suitable for storing and/or executing program code.FIG.7shows, as an example, a computing system700suitable for executing program code related to the proposed method.

As shown in theFIG.7, the computer system/server700is shown in the form of a general-purpose computing device. The components of computer system/server700may include, but are not limited to, one or more processors or processing units702, a system memory704, and a bus706that couple various system components including system memory704to the processor702. Bus706represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limiting, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus. Computer system/server700typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server700, and it includes both, volatile and non-volatile media, removable and non-removable media.

The program/utility, having a set (at least one) of program modules716, may be stored in memory704by way of example, and not limiting, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules716generally carry out the functions and/or methodologies of embodiments of the invention, as described herein.

The computer system/server700may also communicate with one or more external devices718such as a keyboard, a pointing device, a display720, etc.; one or more devices that enable a user to interact with computer system/server700; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server700to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces714. Still yet, computer system/server700may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter722. As depicted, network adapter722may communicate with the other components of the computer system/server700via bus706. It should be understood that, although not shown, other hardware and/or software components could be used in conjunction with computer system/server700. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

Additionally, the storage control system600for operating a storage system can also be attached to the bus system706.

In a nutshell, the inventive concept may be summarized by the following clauses:

1. A computer-implemented method for operating a storage system, the storage system comprising a file system for managing a data object in one or more storage blocks of the storage system, the method comprising

receiving from a file system manager a message indicating that the data object is to be encrypted,

determining, in response to the received message, a set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object, and

rendering content of the unallocated storage blocks of the set unreadable.

2. The method according to clause 1,

wherein the storage system is a tiered storage system comprising at least two storage tiers, and

wherein the determining the set of unallocated storage blocks comprisesidentifying storage blocks of one storage tier of the at least two storage tiers previously allocated to the data object and migrated to the other storage tier of the at least two storage tiers currently allocated to the data object.
3. The method according to clause 1 or 2, wherein the rendering the content of the storage block of the set unreadable comprises erasing the content of the storage blocks of the set.
4. The method according to any of the preceding clauses, wherein the rendering the content of the storage block of the set unreadable comprises overwriting the content of the storage blocks of the set.
5. The method according to any of the preceding clauses, wherein the rendering the content of the storage block of the set comprises encrypting the content of the storage blocks of the set.
6. The method according to any of the preceding clauses, wherein the data object comprises at least one of a file, a logical unit, a logical volume, or a block of data.
7. The method according to any of the preceding clauses,

wherein the storage system is a tiered storage system comprising at least two storage tiers and/or a second storage system, and

wherein the determining the set of unallocated storage blocks comprisesidentifying an unencrypted copy of the data object in another storage tier or the second storage system, andgenerating a message indicative of the unencrypted copy.
8. The method according to clause 7, also comprising

encrypting the unencrypted copy of the data object in another storage tier or another storage system, and

rendering blocks in the other storage tier or other storage system relating to content of the unallocated storage blocks previously allocated to the unencrypted copy of the data object unreadable.

9. The method according to any of the preceding clauses, also comprising

operating a block tracking module in communicative contact with the file system manager, wherein the block tracking module is adapted for keeping track of all allocated blocks and unallocated blocks of all data objects of the storage system enabling a block allocation history.

10. The method according to any of the preceding clauses, wherein the block tracking module is also adapted for keeping track of a data object if it has been moved to another storage system.

11. A storage control system for operating a storage system, the storage system comprising a file system for managing a data object in one or more storage blocks of the storage system, the storage control system comprising

a block tracking module adapted for receiving from a file system manager a message indicating that the data object is to be encrypted,

wherein the block tracking module is adapted for determining, in response to the received message, a set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object, and rendering content of the unallocated storage blocks of the set unreadable.

12. The storage control system according to clause 11,

wherein the storage system is a tiered storage system comprising at least two storage tiers, and

wherein the determining, by the block tracking module, the set of unallocated storage blocks comprisesidentifying storage blocks of one storage tier of the at least two storage tiers previously allocated to the data object and migrated to the other storage tier of the at least two storage tiers currently allocated to the data object.
13. The storage control system according to clause 11 or 12, wherein the rendering, by the block tracking module, the content of the storage block of the set unreadable comprises erasing the content of the storage blocks of the set.
14. The storage control system according to any of the clauses 11 to 13, wherein the rendering, by the block tracking module, the content of the storage block of the set unreadable comprises overwriting the content of the storage blocks of the set.
15. The storage control system according to any of the clauses 11 to 14, wherein the rendering, by the block tracking module, the content of the storage block of the set comprises encrypting the content of the storage blocks of the set.
16. The storage control system according to any of the clauses 11 to 15, wherein the data object comprises at least one of a file, a logical unit, a logical volume, or a block of data.
17. The storage control system according to any of the clauses 11 to 17,

wherein the storage system is a tiered storage system comprising at least two storage tiers and/or a second storage system, and

wherein the determining, by the block tracking module, the set of unallocated storage blocks comprisesidentifying an unencrypted copy of the data object in another storage tier or a second storage system, andgenerating a message indicative of the unencrypted copy.
18. The storage control system according to clause 17, wherein the block tracking module is also adapted for

encrypting the unencrypted copy of the data object in another storage tier or another storage system, and

rendering blocks in the other storage tier or other storage system relating to content of the unallocated storage blocks previously allocated to the unencrypted copy of the data object unreadable.

19. The storage control system according to any of the clauses 11 to 18, wherein the block tracking module is in communicative contact with the file system manager, wherein the block tracking module is adapted for keeping track of all allocated blocks and unallocated blocks of all data objects of the storage system enabling a block allocation history.
20. A computer program product for operating a storage system, the storage system comprising a file system for managing a data object in one or more storage blocks of the storage system, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions being executable by one or more computing systems or controllers to cause the one or more computing systems to

receive from a file system manager a message indicating that the data object is to be encrypted,

determining, in response to the received message, a set of unallocated storage blocks that were previously allocated for storing at least a portion of the data object, and

rendering content of the unallocated storage blocks of the set unreadable.