Banyak yang berubah dalam 8 tahun.
Salah alokasi
fallocate -d filename dapat digunakan untuk melubangi file yang ada. Dari fallocate(1) halaman manual:
-d, --dig-holes
Detect and dig holes. This makes the file sparse in-place,
without using extra disk space. The minimum size of the hole
depends on filesystem I/O block size (usually 4096 bytes).
Also, when using this option, --keep-size is implied. If no
range is specified by --offset and --length, then the entire
file is analyzed for holes.
You can think of this option as doing a "cp --sparse" and then
renaming the destination file to the original, without the
need for extra disk space.
See --punch-hole for a list of supported filesystems.
(Daftar itu:)
Supported for XFS (since Linux 2.6.38), ext4 (since Linux
3.0), Btrfs (since Linux 3.7) and tmpfs (since Linux 3.5).
tmpfs yang ada di daftar itu adalah yang menurut saya paling menarik. Sistem file itu sendiri cukup efisien untuk hanya menggunakan RAM sebanyak yang diperlukan untuk menyimpan kontennya, tetapi membuat konten jarang berpotensi meningkatkan efisiensi itu lebih jauh.
GNU cp
Selain itu, di suatu tempat di sepanjang jalan GNU cp memperoleh pemahaman tentang file jarang. Mengutip cp(1) halaman manual tentang mode defaultnya, --sparse=auto :
file SUMBER jarang terdeteksi oleh heuristik mentah dan file DEST yang sesuai juga dibuat jarang.
Tapi ada juga --sparse=always , yang mengaktifkan salinan file yang setara dengan fallocate -d tidak di tempat:
Tentukan
--sparse=alwaysuntuk membuat file DEST jarang setiap kali file SOURCE berisi urutan nol byte yang cukup panjang.
Saya akhirnya dapat menghentikan tar cpSf - SOURCE | (cd DESTDIR && tar xpSf -) saya one-liner, yang selama 20 tahun adalah cara saya yang abu-abu untuk menyalin file yang jarang dengan kelangkaannya dipertahankan.
Beberapa sistem file di Linux / UNIX memiliki kemampuan untuk "melubangi" file yang sudah ada. Lihat:
- postingan LKML tentang fitur
- FAQ pemotongan file UNIX (cari F_FREESP)
Ini tidak terlalu portabel dan tidak dilakukan dengan cara yang sama secara keseluruhan; sampai sekarang, saya yakin pustaka IO Java tidak menyediakan antarmuka untuk ini.
Jika pelubangan lubang tersedia melalui fcntl(F_FREESP) atau melalui mekanisme lainnya, ini harus jauh lebih cepat daripada loop penyalinan/pencarian.
Saya pikir Anda akan lebih baik mengalokasikan seluruh file terlebih dahulu dan memelihara tabel/BitSet dari halaman/bagian yang ditempati.
Membuat file jarang akan mengakibatkan bagian-bagian tersebut terfragmentasi jika pernah digunakan kembali. Mungkin menghemat beberapa TB ruang disk tidak sebanding dengan kinerja file yang sangat terfragmentasi.