{'fraction_non_alphanumeric': 0.02078740157480315, 'fraction_numerical': 0.0025196850393700786, 'mean_word_length': 4.936448598130841, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Distributed file systems and distributed memory

The model of a single file system shared by all users of a computer is not only convenient but expected by most computer users. It seems natural to extend this model across multiple computers so that all users on a collection of computers share the same file system, thus forming a distributed file system. Similarly, the model of a collection of threads of control sharing the same address space as they cooperate in a computation is a convenient means for exploiting concurrency. This singleaddress-space abstraction is certainly the natural model for use on a sharedmemory multiprocessor. Its convenience for programming is so compelling that it is used increasingly to take advantage of parallelism on distributed systems, where it is called distributed memory. Primarily because of the ubiquity of Sun’s Network File System (NFS), programmers have become accustomed to distributed file systems; they realize how much more convenient such a system is than explicitly copying files across machines. While distributed memory is not so commonplace (existing implementations are research projects), it shows great promise for taking advantage of the collective power of a network of computers for computationally intensive problems. In both distributed file and memory systems, the usual implementation model is one of clients obtaining data from servers. Clients typically maintain a cache of data recently obtained from servers: if data has been fetched previously, reads (in the case of file systems) and loads (in the case of memory systems) can often be satisfied directly from the cache without contacting the server. Writes (in the case of file systems) and stores (in the case of memory systems) can be applied to data in the cache and only later made visible to others by updating the server. For the case of file systems, servers are typically distinct from clients and files are permanently assigned to servers, so that clients always contact the same server for the same file. However, an approach pioneered with distributed memory systems [Li and Hudak 1989] has the server role distributed among all the clients: the “home” of a sharedmemory segment is the client who last modified it. This approach has recently been adopted for distributed file systems [Anderson et al. 1995]. Our primary concerns are performance, how (and whether) the clients’ views of the data are kept consistent, and how machine crashes and network outages are handled. Among the performance concerns are minimizing both network traffic and the latency of responses to user requests. If the data necessary to handle a user request (such as a read operation on a file or a load from memory) are available locally, latency is minimal, but if not, it can be considerable. However, data can now be transferred over high-speed networks faster than from disks. Thus it may be quicker to obtain data over the network from the primary storage of a server machine than from a local disk. In either case, since the impact of network traffic on overall performance is more dependent on the number of messages being transmitted than on their size, it