Changwei Ge
Changwei Ge
I suppose it's a user's decision how to transport and persist nydusd logs. Stdout/stderr and regurlar log files are not conflicted with each other. Moreover, nydusd already provides a CLI...
Close it as it is implemented and merged
> > > > @Zhuchengyu04 Please check why the request to `http://localhost:5000` is redirected to `http://7rx80271.ibosscloud.com`. > > > > > > > > > Sorry, I have no idea...
Sadly, this breaks `nydusctl` ``` gechangwei@n227-089-202 ~/git_repo/nydus-rs/contrib/nydus-test (serde-with)$ sudo nydusctl --sock api_sock info Version: "2.1.0-alpha2" Status: "RUNNING" Profile: "release" Commit: "2c6c75b766c5ae16340537bc3bfd645d27d10640" Backend list: thread 'main' panicked at 'called `Result::unwrap()` on...
failed cargo fmt ``` /home/gechangwei/.cargo/bin/cargo fmt -- --check Diff in /data00/home/gechangwei/git_repo/nydus-rs/api/src/http.rs at line 846: from_api: Receiver, ) -> Result { // Try to remove existed unix domain socket - let...
Otherwise the format issue, LGTM
> We need to enhance the fuse-backend-rs first, to support fusedev and virtiofs concurrently. Do we have any clear obstacle before making any progress on `fuse-backend-rs`?
Customers have to pay for storage space like Aliyun OSS bucket, larger images cost more fees. 30% more fee can hardly be ignored. No matter what compression algorithm is preferred...
> Looks like zstd is the right way, I tested (using acceld) a java image with lz4 and zstd compression: > > ociv1 with gzip: ~234MB nydus with zstd: ~232MB...