File system metadata

Aspects for remote analysis of file system metadata are described. In an example, a computer-readable file from a client system is received. The computer-readable file comprises file system metadata of a file system, and corresponding source location of the file system metadata on a volume of the client system. Thereafter, a target location on a target volume is identified, wherein the target location corresponds to the source location on the volume of the client system. In an example, the file system metadata is replicated onto the target location based on the computer-readable file, for analysis.

BACKGROUND

File systems provide a logical, computer implemented mechanism for storing and retrieving files from storage devices, such as a hard disk drive. A file system may include file system metadata which relates or corresponds to the files stored in the storage devices. The file system utilizes the metadata for implementing a variety of functions, such as storing or retrieving data from appropriate disk locations of the storage devices. In certain instances, the file system metadata may experience inconsistencies or other errors, which may impact the access of files from the file system. In such cases, the errors experienced by the file system may be assessed, and a corresponding patch may be developed for rectifying the file system error.

DETAILED DESCRIPTION

Data is stored in disk storages in an organized manner through file system. The file system provides a logical mechanism for creating, storing and retrieving files in response to requests from client-based applications. The file system may, in turn, be managed through a computing system which manages and controls requests from such client applications. Before the files within the file system may be used, the file system may be specifically made available for access through a process referred to as mounting. For mounting the file system, a computing system intending to access the files may obtain information to determine various attributes, such as file system structure or metadata, pertaining to the file system. Once information pertaining to such attributes are obtained, the file system is mounted.

In certain instances, the file system metadata (interchangeably referred to as metadata), may have errors owing to which the mounting of the file system may be prevented, or may cause runtime failures. Such errors may be caused due to a number of factors, for example, file system metadata inconsistencies, or corruption of the file system metadata. Under such circumstances, the faults may be resolved or fixed through software-based fixes or patches. A patch may be considered as either an executable code or a set of configuration changes for resolving the error with the file system. Such patches are developed by a debugging team by analysing the log files or metadata to identify the error or the root cause. Based on the root cause, the appropriate patch or fix may be developed by the debugging team. The patch may then be installed on client system for resolving or ‘fixing’ the issue which the file system may be experiencing.

However, in certain instances, if the error cannot be determined, a developed patch may be tested on the client system before it may be deployed. In such instances, the patch may be executed onto the client systems under controlled conditions. The appropriate log files (generated as a result of the execution of the patch), or the metadata (which may have been modified by the patch) may then be retrieved and provided to the debugging team for ascertaining the root cause of the issue being faced by the file system. This process may be repeated a certain number of times in order to observe the changes in the log files or the metadata, based on which the error may be determined. Such recurring testing followed by patch development increases the turnaround time for resolving the issue with the file system. This also may burden the client system with repeated testing in cases where the error could not have been determined based on the analysis of the log file or the file system metadata.

In case of any inconsistencies in the file system metadata, file system errors may be resolved by executing file system utilities for checking and correcting any file system inconsistencies. Examples of such utilities include, but are not limited to, FSCK (File System Consistency Check) and CHKDSK (Check Disk). Such file system utilities scan the disk volume for errors. On encountering an error, the file system utility may execute a series of predetermined executable functions for rectifying any error, for example, an inconsistency in the file system metadata.

Issues may also arise in cases where the file system utilities for determining and rectifying file system errors or inconsistencies itself are also experiencing issues. For example, the file system utility may be repeatedly crashing while checking for any inconsistency in the file system. Such issues may arise due to faulty code or an improper update that may have been applied onto computing system hosting the file system. In such a case, resolution of any errors with the file system may not be possible. Even in circumstances when they are functioning without error, execution of such file system utilities may take time for completion for large file system. Furthermore, in cases where the computing system hosting the file system does not have performant computational resources, the time for scanning and fixing any errors in the file system metadata may increase many folds.

Approaches for remote analysis of file system metadata are described. As per the present approaches, the patch may be developed and analysed remotely from a client system on which a file system error may be occurring. In an example, file system metadata of a file system experiencing errors may be determined. Along with the file system metadata, the corresponding locations on a disk volume of the client system (referred to as source location information) is also determined based on the file system metadata. The file system metadata along with the source location information may then be written to a computer-readable file (e.g., a binary file). In some implementations, the file system metadata (referred to as the metadata) may be written to one computer-readable file whereas source location information corresponding to the metadata may be written to another computer-readable file. Such examples also fall within the scope of the claimed subject matter without limitation. In any case, the computer-readable file includes the metadata corresponding to the file system metadata of the client system, but not the client data. In an example, the file system metadata includes file system type, file system size, file system status, free space available on the volume, and information about metadata structures within the file system metadata.

Once the metadata and corresponding source location information is written to the computer-readable file, the computer-readable file may then be transmitted to a remote computing system for analysis. On receipt of the computer-readable file, a target location on a target volume may be identified. In an example, the target location may be selected based on the source location information within the disk volume at which the metadata was stored. With the corresponding target location determined, the file system metadata_may thereafter be replicated onto the target system utilizing the metadata and the source location information written in the computer-readable file. Since the target location corresponds to the source location on the disk storage of the client system, the file system metadata replicated onto the target system matches with the file system on the client system. With the file system metadata replicated onto the target system, further analysis of the metadata may be performed for ascertaining root cause of the error, and accordingly devise a mechanism for resolving the error impacting operation of the file system.

In an example, a software patch may be developed based on analysis of the file system metadata available on the target system. The software patch thus developed may be deployed onto the target system and executed. In response to the execution of the software patch, log files and metadata may be further analyzed for ascertaining the root cause of error. Depending on the log files and the metadata, the software patch may be accordingly modified and deployed onto the target system iteratively until the error is resolved. Since the log files and corresponding metadata are available for analysis at the target system, any delays that would be caused by execution of software patch and subsequent transmission of log files, metadata changes, etc., may be reduced or eliminated. Furthermore, since the software patch is initially deployed onto the target system, any adverse impact on the client data may also be avoided.

In another example, a file system utility may be initiated and executed to process and check the file system metadata for any errors on the target system. As the file system utility executes, it may resolve the issues by changing certain portions of the file system metadata owing to which the errors may have arisen. With the error resolved, the certain portions of the file system metadata which were amended or corrected, are retrieved from the target system, and transmitted to the client system where it may be installed to modify the source file system metadata.

The above-mentioned approaches enable rectification of an error in the file system metadata by replicating it at a testing system, as opposed to carrying out any testing on the client system. This reduces any turnaround time and also prevents client data from being exposed to any preliminary testing. Furthermore, since the testing is performed at a testing system which may have better computational resources for testing as compared to the client system, the testing process may be quicker and more efficient.

The above examples are further described in conjunction with appended figures. It may be noted that the description and figures merely illustrate the principles of the present subject matter. It will thus be appreciated that various arrangements that embody the principles of the present subject matter, although not explicitly described or shown herein, may be devised from the description, and are included within its scope. Moreover, all statements herein reciting principles, aspects, and examples of the present subject matter, as well as specific examples thereof, are intended to encompass equivalents thereof. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components.

FIG.1illustrates an example testing system102for analysing file system metadata of a file system, in accordance with an example of the present subject matter. The testing system102(hereinafter referred to as system102) includes a processor104, and a machine-readable storage medium106which is coupled to, and accessible by, the processor104. The system102may be implemented in any computing system, such as a storage array, server, desktop or a laptop computing device, a distributed computing system, or the like. Although not depicted, the system102may include other components, such as interfaces to communicate over the network or with external storage or computing devices, display, input/output interfaces, operating systems, applications, data, and the like, which have not been described for brevity.

The processor104may be implemented as a dedicated processor, a shared processor, or a plurality of individual processors, some of which may be shared. The machine-readable storage medium106may be communicatively connected to the processor104. Among other capabilities, the processor104may fetch and execute computer-readable instructions, including instructions108, stored in the machine-readable storage medium106. The machine-readable storage medium106may include any non-transitory computer-readable medium including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.

The processor104may fetch and execute machine-readable instructions108(referred to as instructions108) to analyse file system metadata corresponding to file system of a remote client computing system (not shown inFIG.1). As will be explained in the present description, the file system metadata and corresponding information pertaining to the file system metadata is transmitted from a remote client system and retrieved by the system102. Thereafter, the file system metadata retrieved from the client computing system may be analysed to determine the root cause of the error which may be impacting operation of the file system in the client computing system. In an example, the file system metadata from the client computing system may be written to a computer-readable file110. The computer-readable file110thus obtained includes the file system metadata and information indicating location of the file system metadata within a disk storage volume of the client computing system. The computer-readable file110forms the basis on which the file system metadata is replicated onto a target location of a target volume. In an example, the computer-readable file110may be a binary file.

In operation, the processor104may fetch and execute instructions108to analyse file system metadata of a file system, as is described in the following sections. The file system metadata may include a variety of information such as, file system type, file system size, file system status, free space available on the volume, and information about metadata structures within the file system metadata. In one example, the instructions108may further include instructions112to receive a computer-readable file110from a remote client system. The client system may further include a disk storage having a file system for providing storing and maintaining client data. The file system itself may have corresponding metadata which defines a number of attributes, such as name, size, and location, of the file stored in a source location on a disk volume of the client system. In an example, the client system may write the file system metadata and information pertaining to location on a volume of the client system, where the file system metadata (referred to as metadata) is stored. The client system may retrieve the metadata and the source location information and write the same to a computer-readable file110. The computer-readable file110thus generated is transmitted to the system102for analysis.

On receiving the computer-readable file110, the instructions114may then be executed to determine a target location within a target volume which is accessible by the system102. The target volume may be available within the system102or may be at a disk storage which is remotely accessible by the system102. In an example, the target location is such that it corresponds to the source location at which the metadata was stored within the client system. The instructions114may further result in identification of the target location based on the source location information available within the computer-readable file110.

With the target location now determined, the instructions116may be executed to replicate the file system metadata of the client system onto the target location of the target volume, for analysis. In an example, the metadata may be replicated based on the metadata present in the computer-readable file110. Thereafter, the replicated metadata may be further analysed for determining a root cause of the error impacting operation of the file system. In an example, a software patch may be developed to resolve the error with the file system. In another example, a file system utility may be initiated executed on the target location for analysing and checking the file system metadata. An error encountered may be resolved by the file system utility. In an example, the corrected metadata may be transmitted and deployed at the client system. It may be noted that above approaches are provided in conjunction with few examples. However, the scope of the present subject matter is not be restricted to only said examples. The other examples and additional aspects are further described in conjunction with the remaining figures.

FIG.2illustrates a network environment200for remotely analysing file system metadata of a client system, in accordance with an example of the present subject matter. The network environment200includes a client system202utilizing a file system (not depicted inFIG.2). The client system202may be in communication with system102, which in turn analyses and rectifies any errors in the file system of the client system202. In an example, the client system202is in communication with the system102through a network204.

The network204may be a private network or a public network and may be implemented as a wired network, a wireless network, or a combination of a wired and wireless network. The network204may also include a collection of individual networks, interconnected with each other and functioning as a single large network, such as the Internet. Examples of such individual networks include, but are not limited to, Global System for Mobile Communication (GSM) network, Universal Mobile Telecommunications System (UMTS) network, Personal Communications Service (PCS) network, Time Division Multiple Access (TDMA) network, Code Division Multiple Access (CDMA) network, Next Generation Network (NGN), Public Switched Telephone Network (PSTN), Long Term Evolution (LTE), and Integrated Services Digital Network (ISDN).

The client system202may further include instructions206for performing functions in relation to analysis of the file system as explained further. The client system202may further store file system metadata208, which is data related to the file system of the client system202, and other data212. In an example, the file system metadata208may include file system type, file system size, file system status, and free space available on the volume. The client system202may further include a file system utility210which when initiated, may rectify any error, for example, an inconsistency in the file system metadata208. The other data212may include data which is either utilized or generated by the client system202during the analysis of the file system metadata208.

In operation, the instructions206are fetched from a memory of the client system202and executed by a processor of the client system202. In the context of the present subject matter, the instructions206may be executed in instances when the file system of the client system202fails to mount the file system. Such errors may arise due to inconsistencies in the file system metadata208. In an example, the instructions206may be executed to obtain the file system metadata208and information pertaining to the source location in the disk volume, where the file system metadata208is stored. Once the file system metadata208and its corresponding source location is obtained, the execution of the instructions206may result in generation of computer-readable file110. The computer-readable file110thus generated includes the file system metadata208and location information214.

In an example, the file system metadata208may be in the form of metadata block(s)216. The metadata block(s)216may be read upon execution of the instructions206to obtain the metadata contained therein. The metadata thus obtained may then be written to the computer-readable file110. In an example, the computer-readable file110may be a binary file. AlthoughFIG.2depicts a single computer-readable file110to include the file system metadata208as well as the location information214, the file system metadata208and the location information214may be captured and written across multiple such computer-readable files110without deviating from the scope of the present subject matter.

Returning to the present example, the computer-readable file110once obtained may be subsequently transmitted to the system102for analysis and for determining the root cause of the errors which may be impacting operation of the file system of the client system202. The system102may be any remotely located computing device being utilized for analysing the file system metadata208. Once the computer-readable file110is obtained by the system102, the instructions218may be executed. The instructions218may further process the computer-readable file110in the system102. In an example, the instructions218may identify a corresponding target location within a target volume (not shown inFIG.2). In an example, the target volume may either be available on a disk storage present within the system102or may be remotely accessible by the system102over a network (such as the network204). The target volume thus determined is such that it corresponds to or is similar to the source location in the client system202where the file system metadata208was stored. With the target location thus determined, the instructions218may be further executed to write file system metadata208onto the target location. As described previously, the target location in the target volume (which is accessible by the system102) corresponds to the source location in the client system202in which the file system metadata208is stored.

Once the file system metadata208is written onto the target location, a replica of the file system metadata208is now available to the system102. The file system metadata208available at the system102may then be analyzed for determining the root cause of errors. In an example, file system may be activated based on the file system metadata208within the system102. Based upon the activation, log files thus generated may be further analyzed to ascertain the issue with the file system. In another example, a software-based patch220for resolving an error with the file system metadata208may be developed and installed at the system102. Once installed, the software-based patch220may be executed. Any consequent changes caused due to the installation and the subsequent execution of the software-based patch220may be identified. If the error continues to persist, the software-based patch220may be suitably modified and installed. If the error stands resolved through the software-based patch220, the software-based patch220may be transmitted to the client system202for installation, and for resolving the error at the client system202.

In certain cases, the file system metadata208may have inconsistencies which, in turn, may be resulting in errors while activating or mounting the file system. In an example, the system102may further include a test file system utility222(referred to as the test utility222for sake of brevity). Once the file system metadata208is written to the target location and is accessible by the system102, the test utility222may be executed. Examples of the test utility222include, but are not limited to, FSCK (File System Consistency Check) and CHKDSK (Check Disk). Upon execution, the test utility222may scan the file system metadata208for inconsistencies. On detecting any inconsistencies, the test utility222may appropriately modify the metadata block(s)216to rectify any inconsistencies with the file system metadata208to result in amended metadata block(s)224. The amended metadata block(s)224may then be identified and retrieved. Once retrieved, the amended metadata block(s)224may be transmitted to the client system202. The client system202on receiving the amended metadata block(s)224may initiate the instructions206, which on execution may identify metadata block(s)216corresponding to the amended metadata block(s)224. Once identified, the instructions206may be executed to further replace the metadata block(s)216within the client system202.

As also described previously, in certain instances, the file system utility210of the client system202may have become corrupted, resulting in errors in mounting or activating the file system within the client system202. In such instances, the instructions206may be executed to derive information pertaining to the file system utility210. For example, the instructions206when executed may result in determining a version identifier, installation parameters, or information pertaining to any updates installed for the file system utility210. The instructions206may be executed to further transmit the derived information of the file system utility210to the system102. In an example, the derived information may be transmitted at any stage subsequent to the transmission of the computer-readable file110to the system102. Based on the received derived information, the instructions218in the system102may be executed to determine a corresponding test utility222. In an example, the test utility222may be identified from a repository of file system utilities. The test utility222may then be installed within the system102and initiated. If the test utility222resolves the error, it may be concluded that perhaps the file system utility210in the client system202may be corrupted, which in turn was preventing the mounting of the file system onto the client system202.

As explained through the present examples, the file system metadata208may be replicated onto a target location which is accessible by the system102. To such an end, the file system metadata208is initially written to a computer-readable file110(e.g., a binary file). The computer-readable file110is then transmitted to the system102, which then replicates the file system metadata208onto a target location, such that the file system metadata208is accessible (and therefore capable of being analyzed), without interfering with the file system on the client system202.

The manner in which file system metadata208is determined and written to the computer-readable file110is further explained in conjunction withFIG.3.FIG.3illustrates a computing environment300. The environment300includes the client system202. As described in conjunction withFIG.2, the client system202is in communication with the system102over a network204. The client system202may further include a file system which is utilized for storing and for providing access to data. A file system, in one example, may be considered as a structural representation which defines various information pertaining to underlying data. Such information provides the basis for performing a variety of file related functions, such as access, modification, or creation.

In the context of the present example, the client system202may store the file system metadata208. The file system metadata208may further include metadata, namely, a superblock302, index metadata304, usage metadata306, and other metadata308. In an example, a superblock302may be considered as a data structure defining information pertaining to the file system metadata208. For example, the superblock302may include the index metadata304and the usage metadata306. Since the superblock302includes information (i.e., metadata) pertaining index metadata304, usage metadata306, and other metadata308(which again is metadata), it may be said that the superblock302is metadata pertaining to the metadata of the file system.

Returning to the other elements of the file system metadata208, the index metadata304may be a data structure which defines a file system object, such as a file or a directory. Within the data structure, the index metadata304may specify attributes, features, or other information about such file objects. In addition, the index metadata304may also specify locations on disk volume where such metadata may be stored. In an example, the index metadata304may be an inode (also referred to as an index node) in the context of Unix-based file systems. The usage metadata306may specify the extent of usage of the disk volume by the file system metadata208. For example, the usage metadata306may specify the amount for free-disk volume that may be available. In an example, the usage metadata306may be a Storage Bit Map (SBM) in the context of Unix-based file systems.

The different data structures of the file system metadata208may occupy distinct locations within the volume of a disk storage of the client system202. In an example, the file system metadata208may be stored in source volume310, which may further include a plurality of blocks312. Each page may be considered as a singular unit in which data is stored. In the present example, each of the blocks312have been depicted as having a page size of 8 kilobytes (8K). In an example, the location of each of the blocks312may be based on a linear address space with each page location being specified by an indicator which is a multiple of the page size. For example, the first page within the source volume310may be identifiable with a block number 0, the second page being identifiable with a block number 8, and so on and so forth. In the example as illustrated, the superblock302may begin at block number 16. In an example, the block number may be a Logical Block Number (LBN) based on a logical block addressing scheme in the context of Unix-based systems. It may be noted that the present example is only indicative and is not to be construed as a limitation. Any other example or numbering scheme may be employed for identifying the location of pertinent metadata page.

Continuing further, the other elements of the file system metadata208may provide further information pertaining to the file system metadata208. The file system metadata208may span across multiple pages of the source volume310. As described previously, the index metadata304may specify the metadata along with the location of such metadata. In an example, the index metadata304may specify such information as mapping information314, which provides a mapping between the page and the location which stores the contents (i.e., the metadata) of the page. With reference to the example as illustrated inFIG.3, the mapping information314of the index metadata304provides a mapping between the various pages in which the index metadata304is stored, with the locations in the source volume310. For example, ‘page 0’ of the index metadata304(which is different from the first page of the source volume310indicated by block number 0) is mapped onto block number X. This implies that the contents of ‘page 0’ would be available at block number X within the source volume310. In a similar manner, ‘page 1’ would be available at block number Y. Both the block numbers X and Y are collectively depicted as blocks316. In a similar manner, the index metadata304may a data structure for the metadata pertaining to the file system of the client system202.

As described previously, the instructions206within the client system202may execute to determine the file system metadata208and corresponding source location of the file system metadata208, and accordingly, write the same to the computer-readable file110. In an example, the instructions206when executed may scan through the different elements of the file system metadata208. For example, the contents of the computer-readable file110may be generated by reading the respective metadata pages from the different locations on the source volume310. The relevant metadata from the different metadata pages is retrieved and written to the computer-readable file110as file system metadata208. The information pertaining to the different locations from which the corresponding metadata was fetched is written to the computer-readable file110as location information214.

The computer-readable file110is transmitted to the system102wherein a target volume318and a corresponding target location320may be determined. The target volume318and the target location320may correspond to the volume and the locations of the blocks of the file system metadata208in the client system202. In such a case, the target locations320may correspond to the locations (e.g., the LBN X, Y storing ‘page 0’ and ‘page 1’ of the index metadata304) in the source volume310. As a result, the target locations320will be identifiable by the LBN X, Y for the ‘page 0’ and ‘page 1’ of the index metadata304, when replicated onto the target volume318. In an example, the target location320may be determined based on the mapping information available within the computer-readable file110. For example, the computer-readable file110provides both the file system metadata208along with the location information214for the corresponding metadata. These metadata may include location information pertaining to the different elements of the file system metadata208(e.g., the superblock302, the index metadata304, or the usage metadata306). Based on the mapping between different types of metadata (provided in file system metadata208) and their respective source location (provided in the location information214), the system102is to identify the target location320. Once the target location320is determined, the file system metadata208is written at the respective target location320utilizing the file system metadata208within the computer-readable file110. It may be noted that althoughFIG.3depicts target location320to be included within the system102, the target location320may be in a disk storage which is remotely accessible by the system102, without deviating from the scope of the present subject matter.

FIGS.4-6illustrate example methods400,500, and600for remotely analysing metadata of a file system within a client computing system, in accordance with example implementations of the present subject matter. The order in which the above-mentioned methods are described is not intended to be construed as a limitation, and some of the described method blocks may be combined in a different order to implement the methods, or alternative methods.

Furthermore, the above-mentioned methods may be implemented in any suitable hardware, computer-readable instructions, or combination thereof. The steps of such methods may be performed by either a system under the instruction of machine executable instructions stored on a non-transitory computer readable medium or by dedicated hardware circuits, microcontrollers, or logic circuits. For example, the methods may be performed by the one of systems102, and client system202in the network environment200. In an implementation, the methods may be performed under an “as a service” delivery model, where the system102, operated by a provider, receives the file system metadata and performs testing and/or remediated for the client system202, operated by a customer, on-demand or based on a service subscription. Herein, some examples are also intended to cover non-transitory computer readable medium, for example, digital data storage media, which are computer readable and encode computer-executable instructions, where said instructions perform some or all of the steps of the above-mentioned methods.

In an example, the method400may be implemented by testing system102which remotely analyzes the file system metadata208of a client computing system, such as the client system202. At block402, a computer-readable file is received from a client system. The computer-readable file comprises file system metadata and their corresponding source location on a volume of the client system. In an example, the client system202may generate the computer-readable file110by scanning the file system metadata208to identify metadata block(s)216and the corresponding location, within the disk storage, where the file system metadata208is stored. The metadata is written as file system metadata208to the computer-readable file110, with the information pertaining to the source location being written as the location information214. Once generated, the client system202may transmit the computer-readable file110to the system102for analysis of the file system metadata208.

At block404, a target location on a target volume is identified. The target location is such that it corresponds to the source location of the file system metadata on the volume of the client system. For example, the system102determines a target location within a target volume which may be accessible by the system102. The target volume may be available within the system102or may be at a disk storage which is remotely accessible by the system102.

At block406, the file system metadata may be replicated onto the target location based on the computer-readable file received from the client system. For example, the system102may obtain the computer-readable file110. With the target location now determined, the system102may replicate the file system metadata of the client system onto the target location of target volume, for analysis. To this end, the system102may obtain information pertaining to the file system metadata208from the computer-readable file110, and accordingly write the file system metadata208to the target location, such as the target volume318.

At block408, the replicated file system metadata on the target location may be further analyzed. For example, the file system metadata208available at the system102may then be analyzed for determining the root cause of errors. The analysis may involve analyzing a plurality of log files which may have been generated by activating the file system based on the file system metadata208. Based on the log files thus generated, errors which may be impacting the file system may be determined. In some implementations, block408includes causing a test utility to analyse the replicated file system metadata at system102.

At block410, an error which may be impacting the file system, may be resolved. For example, in cases where the file system metadata208may have inconsistencies, a test utility222(e.g., FSCK tool, or a CHKDSK tool) may be installed on the system102. Upon execution, the test utility222may scan the file system metadata208for inconsistencies. On detecting any inconsistencies, the test utility222may appropriately modify the metadata block(s)216to rectify any inconsistencies with the file system metadata208to result in amended metadata block(s)224. If the error stands resolved, the amended metadata block(s)224may then be subsequently transmitted to the client system202, where they may replace metadata block(s)216. In another instance, a software-based patch220may be developed and installed at the system102. The software-based patch220may be executed or caused to be executed. If the software-based patch220is determined to have resolved the error, the software-based patch220may be provided to the client system202, where it may be installed.

FIG.5illustrates a method500for generating a computer-readable file, such as the computer-readable file110. The method500may be implemented in the client system202in which the file system may be experiencing issues. At block502, the file system metadata corresponding to the file system of a client system may be determined. In an example, the metadata may be available as file system metadata208. The file system metadata208may further include metadata, such as superblock302, index metadata304, and usage metadata306. As described previously, the superblock302may include the index metadata304and the usage metadata306. The index metadata304may specify attributes, features, or other information (which is nothing but metadata) about such file objects. In addition, the index metadata304may also specify locations on disk volume where such metadata may be stored. In an example, the index metadata304may be an inode (also referred to as an index node) in the context of Unix-based file systems. The usage metadata306on the other hand specifies the extent of usage of the disk volume by the file system metadata208.

At block504, locations within a volume of a disk storage of the client system storing and maintaining the file system metadata may be determined. For example, the file system metadata208may be stored in source volume310, which may further include a plurality of blocks312, with a location in the source volume310storing the contents of such blocks312. In an example, the location of the content of blocks312the block number may be a Logical Block Number (LBN) based on a logical block addressing scheme in the context of Unix-based systems.

At block506, different elements of the file system metadata may be scanned. For example, the client system202may scan through the different elements of the file system metadata208and reading the respective metadata pages from the different locations on the source volume310.

At block508, a computer-readable file with file system metadata and source location information may be generated. For example, the client system202may retrieve the metadata from the different metadata pages (e.g., stored in any of the LBNs) and is written to the computer-readable file110as file system metadata208. The information pertaining to the different locations (e.g., the LBN X, Y, etc.) from which the corresponding metadata was fetched is written to the computer-readable file110as location information214. In an example, the computer-readable file110is a binary file.

FIG.6illustrates a computing environment600implementing a non-transitory computer readable medium for remotely analyzing a file system of a client computing system, such as the client system202. In an example, the computing environment600includes processor(s)602communicatively coupled to a non-transitory computer readable medium604through a communication link606. In an example implementation, the computing environment600may be for example, the network environment200. In an example, the processor(s)602may have one or more processing resources for fetching and executing computer-readable instructions from the non-transitory computer readable medium604. The processor(s)602and the non-transitory computer readable medium604may be implemented, for example, in system102(as has been described in conjunction with the preceding figures).

The non-transitory computer readable medium604may be, for example, an internal memory device or an external memory device. In an example implementation, the communication link606may be a network communication link, such as of network204. The processor(s)602and the non-transitory computer readable medium604may also be communicatively coupled to a computing device608over the network. The computing device608may be implemented, for example, as a client system202, the file system of which may be experiencing issues.

In an example implementation, the non-transitory computer readable medium604includes a set of computer readable instructions610which may be accessed by the processor(s)602through the communication link606and subsequently executed for analyzing the file system of the client system202. Referring toFIG.6, in an example, the non-transitory computer readable medium604includes instructions610that cause the processor(s)602to process a computer-readable file, such as the computer-readable file110, received from a client system, such as the client system202. The computer-readable file110in turn may include file system metadata (such as file system metadata208), along with its corresponding source location (such as location information214) of the file system metadata on a volume of the client system.

Once the computer-readable file110is received, the instructions610when executed may identify a target location, such as target location320, on a target volume, such as the target volume318. In an example, the target location320corresponds to the source location on the volume, such as the target volume318of the client system202. Once the target volume318and the target locations320are identified, the instructions610may cause the file system metadata208to be flashed onto the target location320based on the computer-readable file. For flashing, the file system metadata208may be written to specific target location320within the target volume318. Thereafter, the instructions610may be executed to cause testing of the file system metadata208replicated onto the target volume318within the system102. In an example, the testing of the file system may be based on patches, such as a software-based patch220. The software-based patch220may be installed initially on the system102to determine whether the software-based patch220resolves the error with the replicated file system at the system102. If the error is resolved, the software-based patch220may be deployed on the client system202for resolving the errors with the file system. In another example, the instructions610may be executed to further execute test utility222within the system102. In such instances, the execution of the test utility222may result in modification of metadata block(s)216to resolve errors to provide amended metadata block(s)224. The amended metadata block(s)224may thereafter be transmitted to the client system202, to replace corresponding metadata block(s)216which were resulting in file system inconsistencies.

Although examples for the present disclosure have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed and explained as examples of the present disclosure.