Memastikan pemesanan direktori berulang di linux


16

Saya menjalankan perusahaan integrasi berkesinambungan yang di-host , dan kami menjalankan kode pelanggan kami di Linux. Setiap kali kami menjalankan kode, kami menjalankannya di mesin virtual yang terpisah. Masalah yang sering muncul adalah bahwa tes pelanggan kadang-kadang akan gagal karena pemesanan direktori kode mereka diperiksa pada VM.

Biarkan saya membahas lebih detail. Pada OSX, sistem file HFS + memastikan bahwa direktori selalu dilalui dalam urutan yang sama. Pemrogram yang menggunakan OSX berasumsi bahwa jika bekerja pada mesin mereka, itu harus bekerja di mana-mana. Tetapi sering tidak bekerja di Linux, karena sistem file linux tidak menawarkan jaminan pemesanan ketika melintasi direktori.

Sebagai contoh, perhatikan ada 2 file, a.rb, b.rb. a.rb mendefinisikan MyObject, dan b.rb menggunakan MyObject. Jika a.rb dimuat terlebih dahulu, semuanya akan berfungsi. Jika b.rb dimuat lebih dulu, ia akan mencoba mengakses variabel yang tidak ditentukan MyObject, dan gagal.

Tetapi lebih buruk dari ini, adalah bahwa hal itu tidak selalu gagal. Karena pemesanan sistem file di Linux tidak dipesan, itu akan menjadi urutan yang berbeda pada mesin yang berbeda. Ini lebih buruk karena kadang-kadang tes lulus, dan kadang-kadang gagal. Ini adalah hasil terburuk yang mungkin terjadi.

Jadi pertanyaan saya adalah, apakah ada cara untuk membuat pemesanan sistem file berulang. Beberapa flag ke ext4 mungkin, yang mengatakan itu akan selalu melintasi direktori dalam urutan tertentu? Atau mungkin sistem file lain yang memiliki jaminan ini?



Selain jawaban benar benar - apa yang "benar" order? Diurutkan secara alfanumerik saja? Atau dengan CTIME? Secara sewenang-wenang secara ajaib? Bagaimana cara pelanggan memastikan pesanan ini pada penempatan? Bagaimana seharusnya informasi pesanan ajaib ini ditransfer kepada Anda?
Michuelnik

@Michuelnik Tidak ada urutan yang benar, tetapi sesuatu yang berulang akan berarti bahwa kita mendapatkan hasil yang sama setiap waktu, yang akan lebih baik daripada tidak sama sekali. Idealnya, kami akan menggunakan pemesanan HFS +, yang menurut saya alfabet.
Paul Biggar

@Michuelnik Masalah ini mempengaruhi tes lebih dari penyebaran Penempatan sebagian besar terjadi di Linux, tetapi jika sesuatu gagal mereka akan memperbaikinya. Tes sebagian besar berjalan pada OSX jadi jika sesuatu gagal itu pasti kesalahan kita.
Paul Biggar

1
@ PaulBiggar: Saya mengerti masalah Anda dan saya tidak dapat menawarkan solusi yang baik (kecuali jika Anda dapat menemukan cara untuk mendeteksi jika urutan file adalah penyebab masalahnya). Tetapi saya tidak setuju bahwa "keberhasilan yang berulang lebih baik daripada kegagalan yang tidak konsisten": Jika lingkungan pengembangan (dan CI) saya memiliki keberhasilan yang berulang tetapi platform penempatan saya memiliki sindrom "kegagalan yang tidak dapat diandalkan" maka saya benar-benar berada di tempat yang buruk. Saya lebih suka melihat kegagalan yang tidak dapat diandalkan sesegera mungkin (idealnya pada sistem pengembangan saya tetapi setidaknya pada sistem CI saya).
Joachim Sauer

Jawaban:


16

Saya tahu itu bukan jawaban yang Anda cari, tetapi saya percaya solusi yang tepat adalah menghindari bergantung pada pemesanan file dalam direktori. Mungkin itu selalu konsisten di semua sistem file HFS +, dan mungkin Anda bisa menemukan cara untuk membuatnya konsisten di ext4 atau sistem file lain juga, tetapi itu akan membuat Anda lebih banyak kesulitan dalam jangka panjang daripada menghemat. Orang lain yang menggunakan aplikasi Anda akan terkejut ketika mereka tidak menyadari bahwa itu hanya kompatibel dengan beberapa jenis sistem file dan bukan yang lain. Urutan dapat berubah jika sistem file dipulihkan dari cadangan. Anda mungkin akan mengalami masalah kompatibilitas karena urutan konsisten HFS + dan urutan konsisten ext4 mungkin tidak sama.

Cukup baca semua entri direktori dan urutkan daftar secara leksikografis sebelum menggunakannya. Sama seperti lshalnya.

Anda menyebutkan file a.rbdan b.rb, tetapi jika kita berbicara tentang file sumber bahasa pemrograman, bukankah setiap file sudah bertanggung jawab untuk memastikan bahwa itu mengimpor semua dependensinya?


Masalahnya adalah kita tidak menulis kode yang sedang kita jalankan. Kami menjalankan kode pelanggan, dan kami tidak memiliki kendali atas bagaimana kode itu ditulis. Jadi masalah kita sebenarnya adalah kita disalahkan atas masalah itu, karena itu bekerja pada mesin mereka tetapi bukan milik kita. Jika kita bisa memaksa semua orang untuk menulis kode yang benar, kita akan melakukannya, tetapi itu tidak dalam kekuatan kita :)
Paul Biggar

10
@ PaulBiggar: tetapi bukankah "itu berjalan di sini tetapi tidak dalam produksi" persis masalah yang seharusnya diperbaiki oleh CI? Dengan kata lain: "Mengapa kode saya rusak di sistem Anda?" harus dijawab dengan "Karena kami melakukan persis apa yang Anda minta!" ;-)
Joachim Sauer

4
Saya tidak tahu tentang orang lain, tetapi ketika kode berfungsi pada mesin saya dan kemudian gagal pada CI atau checkout rekan kerja, saya langsung berasumsi ada sesuatu yang bergantung pada platform atau lingkungan yang perlu saya perbaiki ...
matt5784

1
Tentunya mengembangkan aplikasi pada platform yang tidak Anda gunakan dalam produksi adalah ide yang buruk? Buat mereka berkembang di platform yang sama dengan yang mereka tulis.
Matthew Ife

2
Saya tidak setuju. Saya pikir itu ide yang bagus. Itu membuat lebih banyak kesalahan muncul selama perpindahan dari pengembangan ke server pengujian. Dan dengan demikian kodenya jauh lebih kokoh sebelum pindah ke server produksi. Jadi di dunia yang benar atau teoretis itu jauh lebih baik. Ini adalah dunia yang sama di mana Anda dapat memaksa semua orang untuk menulis kode yang benar, juga dikenal sebagai dreamland.
Hennes

5

Panggilan POSIX di Linux readdir () tidak menjamin pemesanan yang konsisten. Jika Anda ingin hasil yang dipesan, aplikasi yang menangani file bertanggung jawab untuk memesan bagaimana mereka disajikan ke fungsi panggilan.

/programming/8977441/does-readdir-guarantee-an-order

Sekarang, karena Anda mengatakan ini adalah kode pelanggan Anda dan Anda tidak dapat memperbaikinya, Anda mungkin dapat mengubah pustaka yang ditautkan yang digunakan untuk menyediakan panggilan readdir () yang konsisten. Itu akan membutuhkan pekerjaan dan layak untuk ditanyakan sendiri. Untuk referensi cepat untuk itu, lihat http://www.ibm.com/developerworks/linux/library/l-glibc/index.html .

Mengubah ini bisa menelurkan beberapa seri masalah lain yang mungkin tidak bisa saya ramalkan. Anda sangat berhati-hati, tetapi ini bisa menjadi solusi jika pelanggan Anda tidak dapat dididik dengan baik.


1

Didik pelanggan Anda bahwa ada ketergantungan pesanan bawaan yang harus dinyatakan secara eksplisit. Tawarkan untuk membantu pelanggan mengekspresikan ketergantungan sedemikian rupa sehingga kompilasi bekerja pada semua sistem dan minta pelanggan mengadopsi aliran yang berubah yang menangkap ketergantungan urutan kompilasi.

Jika pelanggan ingin dapat mengkompilasi pada mesin lain maka itu akan menjadi kesalahan mereka untuk berpikir bahwa itu datang secara gratis.


Kami pasti akan melakukan ini. Namun, akan bermanfaat jika mereka benar-benar menjadi pelanggan kami sehingga kami bisa melakukan ini.
Paul Biggar

0

Linux Modern (ext4) menambahkan indeks B-tree untuk daftar file. Salah satu efeknya adalah urutan file default tergantung pada hash nama mereka.

Untuk menonaktifkan fitur ini gunakan:

tune2fs -O ^ dir_index

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.