HelloZeroNet / HelloZeroNet/ZeroNet

Zeronet files are highly fragmented on my drive (500 fragments per 500MB file)

Đang mở
#2,604 5 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Ngôn ngữ chính
JavaScript
Star
18.8k
Fork
2.3k
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

Someone already reported that it helped them to speed up the Zeronet after defragmenting their Zeronet drive.
I am using this Zeronet instance for more than 2 years from version 2 to latest version 3.
And i have found that many files are highly fragmented, i mean like for example 500 fragments per 500MB file, reported by Defraggler software.

some examples:
chart.db-wal, 54MB, 622 fragments
content.db-wal, 1GB, 234 fragments
content.db, 1GB, 10 fragments only (maybe due to recent rebuilding the file or such?)
ZeroMe.db, 46MB, 413 fragments
ZeroTalk.db, 35MB, 348 fragments
most fragmented file is one KopyKate video 1GB bigfile, 10 065 fragments.

Maybe no wonder why my HDD is maxed out for many minutes when starting ZN..

Defragmenting is slower than i thought. It taking days and i selected just fraction of files.

Is there any room for improving file handling, so the fragmentation is lower? Maybe there is already an optional feature to preallocate space to a file, i do not know. But i guess this won't be ideal since zeronet is badly made to retain content that is incomplete (no seeder) and it would mean much space wasted for incomplete files? Just publishing my thoughts there.

@HelloZeroNet

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu bằng việc kiểm tra tình trạng phân mảnh được báo cáo trong chart.db-wal, content.db-wal, content.db, ZeroMe.db, ZeroTalk.db và tệp video KopyKate. So sánh cách các tệp chưa hoàn chỉnh và được dựng lại được giữ lại, sau đó xác định liệu một thay đổi trong việc xử lý tệp có thể giảm phân mảnh mà không chiếm trước dung lượng một cách không cần thiết hay không. Được xem là hoàn tất khi có cải thiện đo được và đã bao quát sự đánh đổi liên quan đến nội dung chưa hoàn chỉnh.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
javascript
Lĩnh vực
databases
Loại issue
Lỗi
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
25/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.