{"id":"10403ceb-f569-4ef3-9873-27948c50ba6e","arxiv_id":"1908.11780","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A FUSE-based prototype shows that dual access through POSIX file and object APIs is feasible when files map 1-to-1 to objects, objects are named by inode, and writes are cached before being flushed to the object store.","lead":"This systems paper examines how to let applications access the same data through both standard file-system interfaces and cloud object-store APIs. It reports measurements from a FUSE-based prototype called ObjectFS and argues that write-back caching and inode-based object naming make this dual access practical.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Write-back cache recommended as critical creates stale-read windows for object-API clients that the evaluation never exercises, leaving the dual-access feasibility claim unvalidated.","rationale":"The reader's verdict is CONDITIONAL, and its weakest-assumption analysis identifies exactly the same load-bearing concern: write-back caching and object-API access to data create a stale-read hazard that is acknowledged but neither solved nor evaluated. My stress-test pass confirms that this is the point where the central claim is least secure. The paper's own §3.4 admits that object-based accesses bypass the file-system cache, and §6 elevates write-back caching to a critical component, so the recommended design must explain how an object-API reader obtains a consistent view while dirty data remains in the cache. The proposed UNIFIED cache is the natural solution, but it is only a sketch and is not implemented or measured. The evaluation exercises only single-client, single-interface workloads, so it cannot distinguish between a system that supports coherent dual access and one that merely supports both interfaces independently. This gap does not invalidate the paper's contribution as a position paper with a useful prototype and quantified tradeoffs; it does mean the strongest claim should remain conditional rather than accepted as demonstrated. I therefore see no reason to change the reader's CONDITIONAL verdict, and the concrete consistency test above would settle whether the concern is real or merely an artifact of missing evaluation.","tokens_in":7743,"tokens_out":2510,"duration_ms":28761,"concrete_test":"Add a dual-access consistency test to the prototype using the recommended 1⇒1, inode-number, write-back-cache configuration. (1) Open a file via the POSIX interface, write 64 MB, keep the file open, and issue a GET for the corresponding object through S3; record whether the GET returns the dirty pre-close bytes. (2) Close the file and GET again. (3) Overwrite the object directly via an S3 PUT, then immediately read the file through POSIX. If any of these reads returns stale data, the write-back/local-cache design does not provide coherent dual access and the central feasibility claim needs qualification; if all reads reflect the latest write, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim, that dual access to data through object and POSIX interfaces is feasible with modest overhead, depends on the design in §6: 1⇒1 mapping, inode-number naming, and write-back caching. The load-bearing weak point is the write-back cache. Section 3.4 explicitly states that object-based accesses do not go through the file-system cache, so cloud-native applications can observe outdated data until caches are synced. This is not a peripheral concern: write-back caching is described in §6 as 'critical' to the feasibility of object-based file systems. With the recommended LOCAL cache, a POSIX write that is buffered but not yet flushed is invisible to an object-API GET, violating the expected coherence of dual access. Conversely, an object-API PUT that overwrites the object does not invalidate the local file-system cache, so a subsequent POSIX read can return stale cached bytes. The proposed UNIFIED cache that would re-export an object interface is not implemented or evaluated, and all measurements in §5 use a single client, so cross-client consistency is untested. The experiments measure throughput of each interface in isolation; they never run a concurrent dual-access workload or check whether either interface observes the other's updates. Therefore the evaluation supports the performance claims but does not demonstrate the central feasibility claim under the conditions that matter for storage consolidation.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper argues that file systems and object stores can be unified through dual access, in which the same data is reachable both through a POSIX file-system interface and through native object APIs. It surveys design options for file-to-object mapping, object naming, metadata placement, and caching; describes a FUSE-based prototype called ObjectFS that uses Redis for metadata/cache and supports AWS S3 and OpenStack Swift as backends; and reports experiments on streaming reads, streaming writes, random writes, and renames. On the basis of these measurements it recommends a 1:1 file-to-object mapping, inode-number-based object naming, and write-back caching, and concludes that dual access is feasible with modest overhead.","tokens_in":7909,"tokens_out":3802,"duration_ms":40902,"significance":"If the central claim were fully validated, the paper would make a useful contribution: it sharpens the design space for object-backed file systems, provides an open-source prototype that boots a Linux guest, and quantifies tradeoffs among mapping, naming, and caching choices. The multipart-transfer measurements and the metadata-only rename result for inode-number naming are concrete and reproducible. However, the feasibility claim is only partially supported. The evaluation exercises the file-system and object interfaces in isolation and never tests the coherence conditions that arise in actual dual access, and the one caching design that would provide consistent dual access, the UNIFIED cache, is not implemented. The paper therefore currently demonstrates performance properties of a file system over an object store rather than the end-to-end feasibility of transparent dual access.","major_comments":[{"comment":"The central feasibility claim in §6 depends on write-back caching, which §6 calls 'a critical technology.' Yet §3.4 states that object-based accesses do not go through the file-system cache, so cloud-native applications can observe outdated versions of data until caches are synced. Concretely, with the recommended LOCAL cache, a POSIX write that is buffered but not flushed is invisible to an object-API GET, and an object-API PUT that overwrites an object does not invalidate a locally cached copy, so a later POSIX read can return stale bytes. The evaluation in §5 never runs a concurrent dual-access workload, never has one interface observe modifications made by the other, and uses a single client, so cross-client consistency is untested. The proposed UNIFIED cache that would re-export an object interface and provide consistent dual access is not implemented or evaluated. As a result, the experiments support the throughput-related subclaims but do not validate the paper's central assertion that dual access is feasible under conditions that matter for storage consolidation. The authors should either implement and measure the UNIFIED cache or explicitly scope the feasibility claim to the implemented subset and add a coherence experiment that measures the stale-read window and verifies invalidation from object-API writes.","section":"§3.4, §5, §6"},{"comment":"All performance figures report single measurements with no error bars, repetitions, or statistical summaries. Because the experiments run on AWS t2.2xlarge instances with a network object store, both network and storage performance can vary substantially between runs. The design recommendations in §6—especially 'write-back caching is critical' and the quantitative overhead estimates—rest on comparisons such as 1.7 MB/s versus 15 MB/s in Figure 4 and the rename latency gap in Figure 5. Repeating each workload several times and reporting median and spread (or per-run points) is needed to establish that the observed ordering of design options is stable rather than an artifact of a single sample. This is a load-bearing issue for the evaluation section, not a cosmetic one.","section":"§5, Figures 2–5"},{"comment":"The recommended inode-number naming scheme is presented as preserving object APIs while enabling metadata-only renames, but the paper does not specify or evaluate the reverse direction of dual access: how objects created or overwritten directly through the object API become visible as files in the POSIX namespace. Section 3.2 acknowledges that files created through the object store will need to reference file-system metadata for a name, and that inode-number naming 'hinders dual access' because object-API users must resolve inode numbers. The implementation and evaluation appear to exercise only the file-system-to-object direction, with files written through ObjectFS. Since dual access is bidirectional by definition, the authors should describe the intended mechanism for object-originated data to enter the file-system namespace and measure its correctness and cost, or explicitly state that such object-originated files are outside the current design.","section":"§3.2, §6"}],"minor_comments":[{"comment":"The affiliation reads 'John Hopkins University'; the correct spelling is 'Johns Hopkins University.'","section":"Title page, affiliations"},{"comment":"The caption says 'without no caching'; this should read 'without caching.'","section":"Figure 4 caption"},{"comment":"The sentence 'object stores typically exhibit high latency, which would metadata operations' is missing a verb; it should say something like 'which would slow down metadata operations.'","section":"§3.3, IN-OBJECT bullet"},{"comment":"The right-hand plot in Figure 5 appears to use a logarithmic time axis, but the caption does not state this; please label the axis accordingly.","section":"§5, Figure 5"},{"comment":"The sentence 'Increasing multi-part uploads beyond 8 threads shows no more performance improvement' mixes singular and plural; 'show no further performance improvement' would be clearer.","section":"§5, streaming writes paragraph"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nShort version: this is a worthwhile position paper that maps the design space for object-backed POSIX file systems and contributes a few clean measurements, but it does not demonstrate the central claim it headlines. The dual-access feasibility claim is asserted on the strength of single-interface benchmarks, and the write-back cache they recommend as critical is exactly the piece that breaks dual-access coherence.\n\nWhat's actually new: the paper lays out the mapping, naming, metadata, and caching choices for merging files and objects in a way that's more systematic than typical system papers. The rename experiment is the cleanest result — inode-number naming makes renames metadata-only, while path naming scales with file size or directory population. The random-write comparison between 1-1 and 1-N mappings, with and without caching, also gives a concrete sense of the tradeoffs. The prototype is open source, which is real and reproducible.\n\nWhere the soft spots are: the stress-test note is on target. Section 3.4 explicitly says object-API accesses do not go through the file-system cache, so a POSIX write sitting in the write-back cache is invisible to a GET, and an object PUT does not invalidate cached file data. The paper acknowledges this risk but only floats an unimplemented UNIFIED cache as a possible fix. The evaluation never runs a concurrent dual-access workload, never checks cross-client consistency, and everything is a single client with single measurements and no error bars. Also, the stated minimal object interface (PUT/GET/DEL) is quietly replaced by S3 multipart operations in the experiments, which is fine but should be reconciled.\n\nThese are not fatal for a position paper — the authors are honest about the open problems — but they do mean the central claim, \"dual access is feasible,\" is supported only by inference from separate single-interface measurements. The paper is a roadmap, not a proof.\n\nWho this is for: anyone working on object-backed file systems or storage consolidation. It's a useful framing and the rename data is worth citing. It deserves a serious referee, though the evaluation would need dual-access experiments or a softened claim to move from conditional to acceptance.\n\nMy take: send it to review, but with the expectation that the authors either add a concurrent dual-access experiment or explicitly scope the feasibility claim to access patterns that don't mix interfaces on the same data.","headline":"An honest position paper with a useful taxonomy and clean single-interface measurements, but the central dual-access feasibility claim is not actually tested and the recommended write-back cache has a known, unaddressed stale-read problem.","tokens_in":8512,"tokens_out":1867,"would_cite":false,"duration_ms":20396,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper argues that a single object store can serve both POSIX file applications and native object APIs, and demonstrates the design choices that make dual access work.","keywords":["object storage","POSIX file system","dual access","storage consolidation","file-to-object mapping","write-back caching","FUSE","object-based file system"],"falsifier":"In a single-node ObjectFS mount with write-back caching, write a file through POSIX and then, before the file is closed or flushed, issue a native object GET on the corresponding object; if the GET returns different data from what POSIX wrote, the dual-access consistency claim is false for that design, and a second-client variant would test the cross-client case the evaluation does not cover.","tokens_in":7520,"feed_emoji":"🗄️","tokens_out":6734,"duration_ms":58239,"temperature":0.7,"pith_summary":"This position paper claims that storage sprawl—the spread of data across separate file systems and object stores—can be eliminated by letting one object store serve both POSIX file applications and native object APIs, and that the resulting dual access is feasible if the design is chosen carefully. It lays out the decisions any object-based file system must make—how files map to objects, how objects are named, where metadata lives, and how caching works—and then tests those decisions with ObjectFS, a POSIX-complete file system built with FUSE that runs over S3 and Swift. The experiments show that a 1-to-1 file-to-object mapping, object names based on file-system inode numbers, and write-back caching let ObjectFS track native S3 throughput on streaming reads and cached writes, and make rename a metadata-only operation. Together these results support the paper's conclusion that consolidating file and object workloads onto one platform is practical.","feed_headline":"One object store can serve both file and object APIs","feed_subtitle":"ObjectFS layers POSIX over S3 and hits near-native speed when writes are cached and names use inodes.","key_machinery":"The load-bearing object is the ObjectFS prototype: a FUSE-based, user-space, POSIX-complete file system whose metadata and cache live in a key-value store (Redis) and whose data path goes to generic object stores (S3 and Swift). Its design space is organized by four choices: file-to-object mapping (1:1, 1:N, N:1, hybrid), object naming policy (file name, file path, inode number, user-defined), metadata placement (in-object, in-object metadata, or independent store), and caching (local or unified). The recommended combination—1:1 mapping, inode-number naming, independent metadata, and write-back caching—is what carries the argument, because it preserves native object access, keeps renames metadata-only, and converts many synchronous small writes into fewer large asynchronous transfers.","core_discovery":"The paper's central claim is that dual access to a single object store through both file-system and object APIs is feasible, provided the file system chooses a 1:1 file-to-object mapping, an indirect naming scheme that names objects by inode number, and write-back caching. Under this design, object-native applications can read and write data through the original object API without assembling parts or copying data, while POSIX applications see a complete file system whose metadata operations, such as rename, do not touch object contents. The experiments show ObjectFS tracking native S3 bandwidth for streaming reads with multipart download, reaching near-native throughput on streaming writes only when writes are aggregated in a cache, improving random writes from about 1.7 MB/s to near-sequential speed with caching, and reducing large-file renames from seconds to about 0.005 s under inode naming. The authors present this as evidence that consolidation of file and object workloads on one platform is practical rather than merely hypothetical.","pith_inferences":["The paper's recommended inode naming assumes an external name-to-inode lookup; a natural extension is a user-defined naming policy or a secondary index that lets object-API clients find data without sacrificing rename speed.","The evaluation uses a single mounted client, so the hardest untested case is cross-client consistency with local caches: POSIX writes on one node and object-API reads on another can observe stale data until caches sync.","The proposed UNIFIED cache that re-exports an object interface is a testable architecture: if it also served object GETs and PUTs with cache coherency, it could close the consistency gap the paper leaves open.","The measured gains favor streaming and batch workloads; latency-sensitive synchronous small-write applications remain a stress test that the current design does not claim to satisfy."],"forward_implications":["A single object store can serve existing POSIX applications and cloud-native object applications at the same time, so storage consolidation becomes a plausible way to reduce overprovisioning and backup complexity.","Choosing a 1:1 mapping means object-API clients can GET and PUT whole files directly, but in-place small updates from the file side become read-modify-write cycles unless writes are absorbed by a cache.","Write-back caching is necessary for usable write performance: uncached ObjectFS writes fall below 2 MB/s, while cached writes approach native S3 bandwidth.","Naming objects by inode number makes rename a metadata-only operation (about 0.005 s) instead of a full object copy, at the cost of requiring a name-to-inode lookup for object API access.","Multipart parallel transfer is an important lever: increasing multipart threads from 2 to 8 closes most of the gap between ObjectFS and native S3 for streaming workloads."],"supporting_citations":[{"why":"Provides the S3 object-store backend and the native API baseline that ObjectFS is measured against in the evaluation.","marker":"[1]"},{"why":"Supplies the AWS testbed on which all ObjectFS and S3 performance experiments run.","marker":"[2]"},{"why":"OpenStack Swift is the second object-store backend supported by ObjectFS, demonstrating generality.","marker":"[8]"},{"why":"A generic near-POSIX cloud-backed file system that lacks dual access, defining the gap ObjectFS targets.","marker":"[13]"},{"why":"MarFS provides a near-POSIX interface over cloud objects and illustrates the category of systems that do not offer transparent dual access.","marker":"[18]"},{"why":"Redis serves as both the independent metadata key-value store and the write-back cache in ObjectFS.","marker":"[21]"},{"why":"FUSE is the interface through which ObjectFS exposes its user-space POSIX file system to applications.","marker":"[27]"},{"why":"BlueSky uses caching gateways to aggregate writes, a design alternative whose tradeoff informs ObjectFS's caching choice.","marker":"[28]"},{"why":"CephFS is POSIX complete but tied to its own RADOS store, contrasting with ObjectFS's goal of running over generic object stores.","marker":"[29]"}],"fun_headline_variants":["One object store, two APIs: file and object","ObjectFS: POSIX over S3 with caching boost","Inode naming makes renames 0.005s, not seconds","File and object APIs converge on one backend","Near-native throughput when writes are cached"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The recommendation assumes that a write-back cache can be reconciled with object-API access, since object reads bypass the file system cache and could see stale data until caches are synced, and that unified cache has not been implemented.","fun_headline_variants_meta":{"raw":{"variants":["One object store, two APIs: file and object","ObjectFS: POSIX over S3 with caching boost","Inode naming makes renames 0.005s, not seconds","File and object APIs converge on one backend","Near-native throughput when writes are cached"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000658,"raw_usage":{"total_tokens":2977,"prompt_tokens":879,"completion_tokens":2098,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":495,"completion_tokens_details":{"reasoning_tokens":2022}},"tokens_in":495,"tokens_out":2098,"duration_ms":14859,"temperature":1.0,"reasoning_tokens":2022,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T11:52:16.959688+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"In a single-node ObjectFS mount with write-back caching, write a file through POSIX and then, before the file is closed or flushed, issue a native object GET on the corresponding object; if the GET returns different data from what POSIX wrote, the dual-access consistency claim is false for that design, and a second-client variant would test the cross-client case the evaluation does not cover.","supporting_citations":[{"cited_title":"https://aws","cited_arxiv_id":null,"evidence_quote":"Provides the S3 object-store backend and the native API baseline that ObjectFS is measured against in the evaluation."},{"cited_title":"https://aws.amazon","cited_arxiv_id":null,"evidence_quote":"Supplies the AWS testbed on which all ObjectFS and S3 performance experiments run."},{"cited_title":"https://docs.openstack.org/ swift/latest/","cited_arxiv_id":null,"evidence_quote":"OpenStack Swift is the second object-store backend supported by ObjectFS, demonstrating generality."},{"cited_title":"SCFS: A Shared Cloud-backed File System","cited_arxiv_id":null,"evidence_quote":"A generic near-POSIX cloud-backed file system that lacks dual access, defining the gap ObjectFS targets."},{"cited_title":"MarFS, a Near-POSIX Interface to Cloud Objects","cited_arxiv_id":null,"evidence_quote":"MarFS provides a near-POSIX interface over cloud objects and illustrates the category of systems that do not offer transparent dual access."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Redis serves as both the independent metadata key-value store and the write-back cache in ObjectFS."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"FUSE is the interface through which ObjectFS exposes its user-space POSIX file system to applications."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"BlueSky uses caching gateways to aggregate writes, a design alternative whose tradeoff informs ObjectFS's caching choice."},{"cited_title":"A., B RANDT , S","cited_arxiv_id":null,"evidence_quote":"CephFS is POSIX complete but tied to its own RADOS store, contrasting with ObjectFS's goal of running over generic object stores."}],"review_version":1}