ofstream写大文件出错

纸箱猪 2012-04-25 06:14:03
我的程序在运行过程中会同时向磁盘写两个体积很大的二进制文件。文件A大致是240G,文件B大致是480G。两个文件都是用ofstream对象来维护的。写操作是通过ofstream的write成员函数实现的。

现在的问题是:每次写文件写到64%左右就会出错,write函数的返回值显示写操作没有成功。第一回是在文件A出错,第二回则是在文件B出错。

刚好这几天单位这边的电路在整改。程序两次出错,都正好是电工对配电箱进行操作、对中央空调和好几个房间的电路进行合闸开闸的时候。所以不知道有没有可能是电压不稳而导致磁盘写操作失败。但是我的房间并没有停电,也就是说电脑并没有停机,所以感觉很奇怪。

目前已经排除了单个文件大小限制的原因,因为我试过用ofstream的write成员函数向磁盘写700G的二进制文件,一点问题也没有。

不知有没有办法得知具体的错误原因?我觉得ofstream的几个标志——badbit、eofbit和failbit都给不出很有用的信息。目前正尝试用C标准库的errno和strerror获得出错原因。但是我看了一下errno的说明,要是errno是EIO(I/O error)的话,这信息也没有太大用处。

不知有没有人遇到过这种情况?
...全文
735 22 打赏 收藏 转发到动态 举报
写回复
用AI写文章
22 条回复
切换为时间正序
请发表友善的回复…
发表回复
纸箱猪 2012-05-02
  • 打赏
  • 举报
回复
我已经找到错误的真正原因了。我把这次事件记录在了博客里:http://blog.csdn.net/zzxiang1985/article/details/7526551

谢谢大家给我提供思路。以下是从这篇博客文章的最后几段复制粘贴过来的:

  原来这bug既不是藏在我的程序上,也不是藏在微软的C标准库或C++标准库实现中,而是藏在了NTFS中:http://support.microsoft.com/default.aspx?scid=kb;EN-US;967351。如果程序同时向磁盘写两个大文件,那这两个文件就会被分割成大量的碎片;而在NTFS中,如果一个文件被分割成大量碎片,这个文件的大小就会受到限制。以下是微软帮助和支持给出的技术解释(见刚才给出的网址):


When a file is very fragmented, NTFS uses more space to save the description of the allocations that is associated with the fragments. The allocation information is stored in one or more file records. When the allocation information is stored in multiple file records, another structure, known as the ATTRIBUTE_LIST, stores information about those file records. The number of ATTRIBUTE_LIST_ENTRY structures that the file can have is limited.


  翻译(微软帮助和支持的机器翻译真没法看):

  当一个文件被分割成大量碎片时,NTFS就需要用更多的空间来存储这些碎片在硬盘中的分配信息。这些分配信息被存储为一个或多个文件记录。当这些分配信息被存储为多个文件记录时,NTFS就会用另一个数据结构——ATTRIBUTE_LIST来存储这些文件记录的相关信息,而一个文件能拥有的ATTRIBUTE_LIST_ENTRY结构体的数量是有限的。


  我下载了Contig工具来查看那两个才写了一半的文件。果然,文件中的碎片数量已经达到了几百万之多!


  于是按照微软帮助和支持的说明,我下载安装了补丁,还下载安装了商业软件Diskeeper的试用版。打了补丁后还得将800多GB的E盘格式化,我勒了个去……格式化后,我先把Diskeeper开了起来,然后运行用fwrite的小程序。哇塞,速度比原来快了一倍多,Diskeeper真是给力——我后来试了一下不开Diskeeper,速度跟原来是一样的。当然,重要的是——经过5个多小时,小程序成功运行完毕了!再用Contig查看一下两个文件,碎片数量才几万。


  既然fwrite成功了,那么ofstream应该也能行;而且既然微软已经发步了解决这个问题的补丁,那么不开Diskeeper应该也行。于是我又换回了用ofstream的版本。结果没想到不开Diskeeper的ofstream比开了Diskeeper的fwrite还快——3小时就成功运行完毕了。


  于是,终于解决了这个困扰我一个多星期的问题。这时已经是5月1日,也就是昨天了。


总结:

1. 写程序的时候,如果要对调用错误进行检查并输出错误信息,那么要利用库和系统自身设计的错误信息机制,如C标准库的errno和Windows系统的GetLastError()。这些信息会对查错提供很大的帮助。如果我一开始就用了errno和GetLastError(),那就能早几天解决这个问题了。

2. 如果要往磁盘写大量的数据,尽量将这些数据合并成一个文件写,而不是分开多个文件写。这样一来可以减少文件碎片,二来可以加快写文件的速度。

ri_aje 2012-05-02
  • 打赏
  • 举报
回复
glutPostRedisplay
纸箱猪 2012-04-27
  • 打赏
  • 举报
回复
不过目前至少可以确定不是电的问题了,因为这次出错是在昨天晚上,办公楼里就只有我一个人。
纸箱猪 2012-04-27
  • 打赏
  • 举报
回复
我翻了翻VS2010的STL代码,发现basic_ofstream中管理缓冲区的成员(一个basic_filebuf对象)会调用fwrite,而fwrite的第三个参数(count)为负时就会出现EINVAL错误。但是这个参数是size_t类型的啊,应该是无符号类型,而且在64位下应该就是64位。而且为什么我单纯写一个700GB的文件就不会出错呢?

我现在写了一个新的小程序,让它纯粹同时写两个文件:一个240GB左右,一个480GB左右,看看会不会出错。

明天打算把实际程序中的ofstream换成文件指针FILE*,直接用C语言标准库,每次fwrite一个float或一个double,看看行不行。
纸箱猪 2012-04-27
  • 打赏
  • 举报
回复
[Quote=引用 17 楼 的回复:]

引用 16 楼 的回复:

郁闷大了。结果这回在55%就出错了。errno是EINVAL:Invalid argument。


估计某个int类型的值溢出了,就算你64位也不鸟你。
[/Quote]

莫非是ofstream内部的某个int值。真要是那样的话可确实不能用ofstream了。
qq120848369 2012-04-27
  • 打赏
  • 举报
回复
[Quote=引用 16 楼 的回复:]

郁闷大了。结果这回在55%就出错了。errno是EINVAL:Invalid argument。
[/Quote]

估计某个int类型的值溢出了,就算你64位也不鸟你。

纸箱猪 2012-04-27
  • 打赏
  • 举报
回复
郁闷大了。结果这回在55%就出错了。errno是EINVAL:Invalid argument。
纸箱猪 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 4 楼 的回复:]

既然你说写单个文件没问题,那要是把两个文件分开写呢,我是说不要同时写。另外,你是什么系统呢,我觉得 ostream 可能给不出具体的原因了,只能靠系统自己的函数了。
[/Quote]

现在正在跑第三遍,祈祷这几天电工不会有什么动作。如果又出错了,就写一个小程序,试一下你说的方法,先写一个文件再写另一个文件。不过我觉得这和我现在出错的实际程序好像没啥区别,因为我的程序是单线程的。

现在我是在Win7上跑程序。莫非要用Windows API中的WriteFile?可以的话真想尽量避免写系统本地的API,因为我的程序是有跨平台要求的,过一段时间还要在Linux上运行。

另外我现在正在找S.M.A.R.T.工具对磁盘进行监视,但不太熟悉,正在摸索中。
ri_aje 2012-04-26
  • 打赏
  • 举报
回复
既然你说写单个文件没问题,那要是把两个文件分开写呢,我是说不要同时写。另外,你是什么系统呢,我觉得 ostream 可能给不出具体的原因了,只能靠系统自己的函数了。
ri_aje 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 的回复:]

引用 11 楼 的回复:

也许是其他地方的错误吧,我以前做过一个导数据库的程序,最后发现居然是ADO临时记录会存在内存里,内存消耗干了,数据也就不写了,最后造成出错。


这让我想到是不是要隔一段时间手工flush一下。
[/Quote]
我记得 ostream 会自动 flush 的。
纸箱猪 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 13 楼 的回复:]

_lseeki64
[/Quote]

可我不需要移动文件指针,只是不停地写。
赵4老师 2012-04-26
  • 打赏
  • 举报
回复
_lseeki64
纸箱猪 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 11 楼 的回复:]

也许是其他地方的错误吧,我以前做过一个导数据库的程序,最后发现居然是ADO临时记录会存在内存里,内存消耗干了,数据也就不写了,最后造成出错。
[/Quote]

这让我想到是不是要隔一段时间手工flush一下。
lurel 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 10 楼 的回复:]

引用 9 楼 的回复:

推荐用api操作吧,ofstream在过个进程同时操作很难保证不出问题。


多个进程?可是我只有一个进程,一条线程。
[/Quote]

也许是其他地方的错误吧,我以前做过一个导数据库的程序,最后发现居然是ADO临时记录会存在内存里,内存消耗干了,数据也就不写了,最后造成出错。
纸箱猪 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 9 楼 的回复:]

推荐用api操作吧,ofstream在过个进程同时操作很难保证不出问题。
[/Quote]

多个进程?可是我只有一个进程,一条线程。
lurel 2012-04-26
  • 打赏
  • 举报
回复
推荐用api操作吧,ofstream在过个进程同时操作很难保证不出问题。
纸箱猪 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 7 楼 的回复:]

ulimit -a看看filesize限制在多少了,看看errno是不是EFBIG。
[/Quote]

ulimit是Linux的命令吧。根据我的试验,应该不会是文件大小限制的问题,因为单个文件700G是没问题的。目前正在用errno,要等明天才能看到结果了。
qq120848369 2012-04-26
  • 打赏
  • 举报
回复
ulimit -a看看filesize限制在多少了,看看errno是不是EFBIG。
ri_aje 2012-04-26
  • 打赏
  • 举报
回复
[Quote=引用 5 楼 的回复:]

引用 4 楼 的回复:

既然你说写单个文件没问题,那要是把两个文件分开写呢,我是说不要同时写。另外,你是什么系统呢,我觉得 ostream 可能给不出具体的原因了,只能靠系统自己的函数了。


现在正在跑第三遍,祈祷这几天电工不会有什么动作。如果又出错了,就写一个小程序,试一下你说的方法,先写一个文件再写另一个文件。不过我觉得这和我现在出错的实际程序好像没啥区别,因为我的程序是单线……
[/Quote]
嗯,这种问题确实很难调,我说的建议你用系统函数,不是说一直用,只是说现在调试的过程用他们帮你找问题,明白原因了以后,还可以用ostream,只不过写的时候,如果可能的话,注意避免问题.
纸箱猪 2012-04-25
  • 打赏
  • 举报
回复
[Quote=引用 2 楼 的回复:]

难道能够写超过 2g的文件??或者我记错了.
write的第二个参数不是long?还是long是8字节的?
[/Quote]

write的第二个参数是某种整型(我想应该是size_t),的确有字长的限制。但我是在一个循环中调用很多次write,每次只写一个float或一个double。

另外补充一下,我的程序是64位的。
加载更多回复(1)

64,282

社区成员

发帖
与我相关
我的任务
社区描述
C++ 语言相关问题讨论,技术干货分享,前沿动态等
c++ 技术论坛(原bbs)
社区管理员
  • C++ 语言社区
  • encoderlee
  • paschen
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
  1. 请不要发布与C++技术无关的贴子
  2. 请不要发布与技术无关的招聘、广告的帖子
  3. 请尽可能的描述清楚你的问题,如果涉及到代码请尽可能的格式化一下

试试用AI创作助手写篇文章吧