Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There should be a caching wrapfs #223

Open
hmeine opened this issue Nov 23, 2015 · 7 comments
Open

There should be a caching wrapfs #223

hmeine opened this issue Nov 23, 2015 · 7 comments

Comments

@hmeine
Copy link
Contributor

hmeine commented Nov 23, 2015

For networking-based filesystems, one is often interested in some kind of local cache. As far as I can see, that would be another good use case for fs.wrapfs, right?

@travcunn
Copy link

travcunn commented Dec 9, 2015

Yes fs.wrapfs would be perfect. The implementation really depends on what type of filesystem you're trying to wrap and your use case though.

@hmeine hmeine mentioned this issue Dec 9, 2015
@arekbulski
Copy link

There are classes for caching single files and filesystem metadata, but not complete filesystem:
https://github.com/PyFilesystem/pyfilesystem/blob/master/fs/remote.py

@hmeine
Copy link
Contributor Author

hmeine commented Jan 6, 2016

Yes, I think CacheFS comes close, but I would like to have an additional cache of files that were read. So, one would configure a local cache directory and maximum cache size (after which the oldest files are purged), and all files would first be copied there and reused instead of re-downloaded. The metadata would obviously be solved by CacheFS[Mixin] already.

@mguillau
Copy link

Hi,

I'm working on a WrapFS subclass implementing the LRU caching scheme (wikipedia entry). On top of the wrapped FS, one provides another FS used for caching and the max size of the cache. The consistency is checked based on md5, so it's compatible with s3's etag. Would you consider a pull request when I'm done?

M.

@arekbulski
Copy link

arekbulski commented Aug 1, 2016

I think you could close this issue, unless you have some code to submit. You made a point.

@lurch
Copy link
Contributor

lurch commented Aug 1, 2016

IMHO this is a perfectly valid suggestion / request, so there's no point closing it.

@arekbulski
Copy link

I agree. Some maintainers close less prospective issues when there is no active work to discuss.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants