🚀 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