2011-09-06 23 views
5

Tôi duy trì một ứng dụng thu thập dữ liệu từ một bộ dữ liệu và nối dữ liệu đó vào cuối tệp nhị phân. Bản chất của hệ thống này là tập tin có thể phát triển các bước nhỏ (> 4 gigabyte) nhỏ tại một thời điểm. Ngày của người sử dụng ứng dụng của tôi đã thấy các trường hợp trên phân vùng NTFS của mình, nơi các nỗ lực chắp thêm dữ liệu không thành công. Lỗi được báo cáo là kết quả của lệnh gọi hàm fflush(). Khi điều này xảy ra, giá trị trả về cho GetLastError() là 665 (ERROR_FILE_SYSTEM_LIMITATION). MSDN cho những điều sau đây description cho lỗi nàyYếu tố nào có thể dẫn đến lỗi Win32 665 (giới hạn hệ thống tệp)?

Các hoạt động yêu cầu không thể được hoàn thành do một giới hạn hệ thống tập tin

Một tìm kiếm cho mã lỗi này trên google cho kết quả liên quan đến SQL server với RẤT lớn các tệp (hàng chục gigabyte) nhưng, hiện tại, tệp của chúng tôi nhỏ hơn nhiều. Người dùng này không thể tải tệp vượt quá 10 gigabyte. Chúng tôi có thể tạm thời khắc phục tình huống khi chúng tôi thực hiện một số thao tác (như sao chép tệp) để buộc một số loại viết lại trong hệ thống tệp. Thật không may, tôi không chắc chắn những gì đang xảy ra để đưa chúng ta vào tình trạng này ngay từ đầu. Điều kiện cụ thể trong hệ thống tệp NTFS có thể dẫn đến lỗi cụ thể này được báo cáo khi có lệnh gọi fflush()?

+0

lẽ [này] (http://blogs.technet.com/b /mikelag/archive/2011/02/09/how-fragmentation-on-incorrectly-formatted-ntfs-volumes-affects-exchange.aspx) giúp. Đó là về Exchange, nhưng có lẽ bạn có thể tìm thấy một cái gì đó ở đó. –

+2

http://support.microsoft.com/default.aspx?scid=kb;EN-US;967351 –

Trả lời

9

Điều này có vẻ như bạn đã đạt đến giới hạn trong phân đoạn của tệp. Nói cách khác, mỗi tuôn ra là tạo ra một mức độ mới (fragment) của tập tin và hệ thống tập tin là có một thời gian khó tìm một nơi để theo dõi danh sách các mảnh vỡ. Điều đó sẽ giải thích tại sao việc sao chép tập tin sẽ giúp - nó tạo ra một tập tin mới với ít mảnh hơn.

Một điều khác có thể hoạt động là chống phân mảnh tệp (sử dụng tiện ích contig của Sysinternals bạn có thể làm như vậy khi đang sử dụng). Bạn cũng có thể sử dụng contig để cho bạn biết số lượng tệp mà tệp có. Tôi đoán nó lên đến một triệu đô.

Nếu bạn phải xóa tệp thường xuyên và không thể chống phân mảnh, điều bạn có thể làm đơn giản là tạo tệp khá lớn ngay từ đầu (để phân bổ không gian cùng một lúc) rồi ghi vào byte kế tiếp tệp thay vì nối thêm.

Nếu bạn dũng cảm (và quá trình của bạn có quyền truy cập quản trị viên), bạn có thể chống phân mảnh các tập tin chính mình với một vài cuộc gọi API: http://msdn.microsoft.com/en-us/library/aa363911(v=VS.85).aspx

+0

Tôi không biết tiện ích contig và nó dường như là một công cụ hữu ích. Thật không may, nó đã không thể chống phân mảnh tập tin. Mã lỗi giống nhau (665). Rõ ràng contig là không thể chống phân mảnh một tập tin đó là quá phân mảnh. –

+0

@Jon: Vâng, tôi e rằng bạn sẽ phải chạy 'contig' * trước đó * nó lớn đến thế. 'Contig -a' nói gì về tệp của bạn? – Gabe

+0

contig -a báo cáo rằng tệp có 77771 phân đoạn. Tôi đã sao chép các tập tin và contig sau đó báo cáo rằng các tập tin có một mảnh. Số lượng các mảnh vỡ được báo cáo có vẻ giống như một loại giới hạn lẻ trong hệ thống tệp. Có một số loại giới hạn cứng hay có một số loại gián đoạn đang diễn ra ở đây? –