Pith. sign in

REVIEW 3 major objections 5 minor 29 references

Towards Marrying Files to Objects

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 1908.11780 v1 pith:FCX2Z6K4 submitted 2019-08-21 cs.DC

Kunal Lillaney (1) , Vasily Tarasov (2) , David Pease (2) , Randal Burns (1) ((1) Johns Hopkins University , (2) IBM Research-Almaden) This is my paper · ORCID
classification cs.DC
keywords objectstoragePOSIXfilesystemdualaccessconsolidationfile-to-objectmappingwrite-backcachingFUSEobject-based
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

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.

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 (3)
  1. [§3.4, §5, §6] 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.
  2. [§5, Figures 2–5] 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.
  3. [§3.2, §6] 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.
minor comments (5)
  1. [Title page, affiliations] The affiliation reads 'John Hopkins University'; the correct spelling is 'Johns Hopkins University.'
  2. [Figure 4 caption] The caption says 'without no caching'; this should read 'without caching.'
  3. [§3.3, IN-OBJECT bullet] 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.'
  4. [§5, Figure 5] 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.
  5. [§5, streaming writes paragraph] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the feasibility claim is supported by measurements against an external S3 baseline, not by fitted inputs or self-citation.

full rationale

The paper is a position paper whose central claim, that dual access through object and file system APIs is feasible, is supported by experimental measurements of a prototype against native AWS S3 as an external baseline. The design options in Sections 3.1-3.4 are presented as a design space rather than as derived predictions, and the recommendations in Section 6 (1=>1 mapping, inode-number naming, write-back caching) are inferred from measured throughput and latency tradeoffs, not assumed as inputs. The experiments report raw I/O throughput and rename latencies, and no parameter is fitted and then renamed as a prediction. The only self-citation is reference [27] on FUSE performance, which is background context and is not load-bearing for the paper's central feasibility claim. Identified limitations, such as the stale-read window for object-API clients in Section 3.4 and the single-client evaluation in Section 5, are correctness and validation concerns, not circularity: they do not make the conclusion equivalent to its inputs. Therefore the paper exhibits no significant circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on assumptions about object-store behavior and POSIX completeness, not on fitted model parameters. The only tunables in the experiments are settings such as 4 MB record size and 2/4/8 multipart threads, which are varied by design and are not fit to any target. ObjectFS is a concrete open-source prototype, so no invented physical entities are involved.

assumptions (4)
  • domain assumption A generic object store can be represented by the minimal interface PUT(name, data), GET(name), DEL(name) with a flat namespace.
    Stated in Section 3. The paper's own evaluation relies on S3 multipart upload/download and server-side copy, which are outside this minimal interface, so the assumption is not consistently honored.
  • domain assumption The measured AWS S3 behavior (high latency, efficient large transfers, server-side copy) generalizes to the target object stores (S3, Swift).
    The evaluation uses only AWS S3 on one instance type; the paper generalizes conclusions to generic object stores.
  • domain assumption A FUSE-based user-space file system with Redis metadata and cache can provide POSIX-complete semantics for the tested workloads.
    Section 4 claims support for all major POSIX operations and demonstrates by booting Linux; no conformance suite or multi-client test is reported.
  • domain assumption The target object stores are high-latency and operate efficiently only when transferring large objects, so multipart transfers and write-back caching are required for performance.
    Stated in Section 3.4 and Section 4; this motivates the caching conclusion but is an empirical claim about object-store behavior, transferred from S3 to all object stores.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards Marrying Files to Objects." pith.science (2026). https://pith.science/paper/FCX2Z6K4

@misc{pith2026190811780,
  author       = {Pith},
  title        = {Pith review of: Towards Marrying Files to Objects},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FCX2Z6K4}},
  note         = {Machine review of arXiv:1908.11780}
}
read the original abstract

To deal with the constant growth of unstructured data, vendors have deployed scalable, resilient, and cost effective object-based storage systems built on RESTful web services. However, many applications rely on richer file-system APIs and semantics, and cannot benefit from object stores. This leads to storage sprawl, as object stores are deployed alongside file systems and data is accessed and managed across both systems in an ad-hoc fashion. We believe there is a critical need for a transparent merger of objects and files, consolidating data into a single platform. Such a merger would extend the capabilities of both object and file stores while preserving existing semantics and interfaces. In this position paper, we examine the viability of unifying object stores and file systems, and the various design tradeoffs that exist. Then, using our own implementation of an object-based, POSIX-complete file system, we experimentally demonstrate several critical design considerations.

Figures

Figures reproduced from arXiv: 1908.11780 by the authors.

Figure 1
Figure 1. An overview of ObjectFS and the data flow [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Streaming read performance on native S3 and [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Streaming write performance on native S3 and [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: Rename latency for different object naming [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 29 canonical work pages

  1. [1]

    https://aws

    Amazon Simple Storage Service (S3). https://aws. amazon.com/s3/

    work page

  2. [2]

    https://aws.amazon

    Amazon Web Services Pricing. https://aws.amazon. com/pricing

    work page

  3. [3]

    https://github.com/Azure/ azure-storage-fuse

    Blobfuse. https://github.com/Azure/ azure-storage-fuse

    work page

  4. [4]

    https://github.com/ GoogleCloudPlatform/gcsfuse

    GCSfuse. https://github.com/ GoogleCloudPlatform/gcsfuse. 5

    work page

  5. [5]

    https://github.com/kahing/goofys

    Goofys. https://github.com/kahing/goofys

    work page

  6. [6]

    https://cloud.google

    Google Cloud Platform Pricing. https://cloud.google. com/pricing

    work page

  7. [7]

    https://cloud.microsoft

    Microsoft Azure Pricing. https://cloud.microsoft. com/en-us/pricing

    work page

  8. [8]

    https://docs.openstack.org/ swift/latest/

    OpenStack Swift. https://docs.openstack.org/ swift/latest/

    work page

Show all 29 references
  1. [9]

    https://github.com/skoobe/riofs

    RioFS. https://github.com/skoobe/riofs

  2. [10]

    https://github.com/s3fs-fuse/ s3fs-fuse

    S3Fuse. https://github.com/s3fs-fuse/ s3fs-fuse

  3. [11]

    https://bitbucket.org/nikratio/s3ql/

    S3QL. https://bitbucket.org/nikratio/s3ql/

  4. [12]

    https://github.com/ovh/svfs

    SVFS. https://github.com/ovh/svfs

  5. [13]

    SCFS: A Shared Cloud-backed File System

    B ESSANI , A., M ENDES , R., O LIVEIRA , T., N EVES , N., C OR- REIA , M., P ASIN , M., AND VERISSIMO , P. SCFS: A Shared Cloud-backed File System. In 2014 USENIX Annual Techni- cal Conference (USENIX ATC 14) (Philadelphia, PA, 2014), USENIX Association, pp. 169–180

    2014

  6. [14]

    Criti- cal Capabilities for Object Storage

    C HANDRASEKARAN , A., B ALA , R., AND LANDERS , G. Criti- cal Capabilities for Object Storage. Gartner (2017)

    2017

  7. [15]

    Lessons Netflix learned from the AWS outage

    C OCKROFT , A., H ICKS , C., AND ORZELL , G. Lessons Netflix learned from the AWS outage. Netflix Techblog (2011)

    2011

  8. [16]

    The Cost of Doing Science on the Cloud: The Mon- tage Example

    D EELMAN , E., S INGH , G., L IVNY, M., B ERRIMAN , B., AND GOOD , J. The Cost of Doing Science on the Cloud: The Mon- tage Example. In High Performance Computing, Networking, Storage and Analysis, 2008. SC 2008. International Conference for (2008), IEEE, pp. 1–12

    2008

  9. [17]

    Distributed Caching with Memcached

    F ITZPATRICK , B. Distributed Caching with Memcached. Linux J. 2004, 124 (Aug. 2004), 5–

    2004

  10. [18]

    MarFS, a Near-POSIX Interface to Cloud Objects

    I NMAN , J., V INING , W., R ANSOM , G., AND GRIDER , G. MarFS, a Near-POSIX Interface to Cloud Objects. ; Login 42 , LA-UR–16-28720; LA-UR–16-28952 (2017)

    2017

  11. [19]

    D., AND LEEK , J

    L ANGMEAD , B., H ANSEN , K. D., AND LEEK , J. T. Cloud- scale RNA-sequencing differential expression analysis with Myrna. Genome biology 11, 8 (2010), R83

    2010

  12. [20]

    OD RISCOLL , A., D AUGELAITE , J., AND SLEATOR , R. D. Big data, Hadoop and cloud computing in genomics. Journal of Biomedical Informatics 46, 5 (2013), 774–781

    2013

  13. [21]

    S ANFILIPPO , S., AND NOORDHUIS , P. Redis. http:// redis.io

  14. [22]

    B., AND HASKIN , R

    S CHMUCK , F. B., AND HASKIN , R. L. GPFS: A Shared-Disk File System for Large Computing Clusters. In FAST (2002), vol. 2

    2002

  15. [23]

    Lustre: Building a file system for 1000- node clusters

    S CHWAN , P., ET AL . Lustre: Building a file system for 1000- node clusters. In Proceedings of the 2003 Linux symposium (2003), vol. 2003, pp. 380–386

    2003

  16. [24]

    Data Center Storage: Cost-Effective Strategies, Im- plementation, and Management

    S MITH , H. Data Center Storage: Cost-Effective Strategies, Im- plementation, and Management. CRC Press, 2016

    2016

  17. [25]

    F., R EINSEL , D., AND MINTON , S

    T URNER , V., G ANTZ , J. F., R EINSEL , D., AND MINTON , S. The Digital Universe of Opportunities: Rich Data and the In- creasing Value of the Internet of Things.IDC Analyze the Future (2014), 5

    2014

  18. [26]

    Rethinking Data Management for Big Data Scientific Workflows

    V AHI , K., R YNGE , M., J UVE , G., M AYANI, R., AND DEEL - MAN , E. Rethinking Data Management for Big Data Scientific Workflows. In 2013 IEEE International Conference on Big Data (Oct 2013), pp. 27–35

    2013

  19. [27]

    V ANGOOR , B. K. R., T ARASOV , V., AND ZADOK , E. To FUSE or Not to FUSE: Performance of User-Space File Systems. In FAST (2017), pp. 59–72

    2017

  20. [28]

    V RABLE , M., S AVAGE, S., AND VOELKER , G. M. BlueSky: A Cloud-backed File System for the Enterprise. In Proceedings of the 10th USENIX Conference on File and Storage Technolo- gies (Berkeley, CA, USA, 2012), FAST’12, USENIX Associa- tion, pp. 19–19

    2012

  21. [29]

    A., B RANDT , S

    W EIL , S. A., B RANDT , S. A., M ILLER , E. L., L ONG , D. D. E., AND MALTZAHN , C. Ceph: A Scalable, High- performance Distributed File System. In Proceedings of the 7th Symposium on Operating Systems Design and Implementation (Berkeley, CA, USA, 2006), OSDI ’06, USENIX Asso...

    2006

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.