FSSpec support for TorchSnapshot?

[reyoung]

🚀 The feature

Use fsspec as TorchSnapshot's backend.

Motivation, pitch

FSSpec is the FileSystem abstraction standard of Python in fact. It supports many backends like s3, gcs, webdav and supports asyncio feature, transparent compression and so on.

FSSpec is also widely adopted by Torch-related communities, like huggingface/datasets uses fsspec as the storage backend.

Both Python users and Torch users are familiar with fsspec , it could be better the TorchSnapshot can adopt fsspec as the storage backend.

Alternatives

There are two major alternatives:

1. Writing the storage backend abstraction in the TorchSnapshot repo, however

• there are so many fs backends that may need to be implemented, and each implementation should contain unit tests. It is hard to write and test them all in TorchSnapshot.
• it is hard to write and merge in-house storage to TorchSnapshot. For example, some companies may have customized distributed file systems for saving checkpoints. Should they check in their implementations to TorchSnapshot? fsspec's plugin can be an individual package, like oss for Alibaba cloud storage.

2. Use PyFilesystem. I think fsspec is used by more projects and people. The fsspec have documentation about why PyFilesystem is bad. Quoted as

   It might have been conceivable to reuse code in pyfilesystems, which has an established interface and several implementations of its own. However, it supports none of the critical features for cloud and parallel access, and would not be easy to coerce. Following on the success of s3fs and gcsfs, and their use within Dask, it seemed best to have an interface as close to those as possible. See a discussion on the topic.

Additional context

No response

[pytorch-bot[bot]]

:link: Helpful Links

:test_tube: See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/tutorials/2597

• :page_facing_up: Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

:white_check_mark: No Failures

As of commit 7d763ac2c35d6b04b07e0c0a017134566837498e with merge base 77aec058e3989747afd42eadc08bd8cce909023b (): :green_heart: Looks good so far! There are no failures yet. :green_heart:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[facebook-github-bot]

Hi @dkangala!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[github-actions[bot]]

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.