求助，c中能否创建[color=red]100G[/color]文件，急！！！

superdoctor

100G的文件即使能操作那有什么实际意义呢？磁盘交换基本上会让速度变得没有办法忍受啊，你的内存我估计也没有100G吧

还是想想怎么分割这100G吧

FH

原帖由 "superdoctor" 发表：
100G的文件即使能操作那有什么实际意义呢？磁盘交换基本上会让速度变得没有办法忍受啊，你的内存我估计也没有100G吧

还是想想怎么分割这100G吧

1字节的磁盘交换能忍受吗？我不觉得它和100G在磁盘交换问题上有什么不同。

superdoctor

原帖由 "FH" 发表：

1字节的磁盘交换能忍受吗？我不觉得它和100G在磁盘交换问题上有什么不同。

如果是1字节那就放到内存中，因为程序只能处理在内存中的数据锕，如果某些数据在内存中没有发现当然会发生磁盘交换，会有一部分内存中的东西交换回磁盘然后让需要用的数据读入到内存啊

如果你数据这样交换量大的话当然是瓶颈啦，磁盘速度比内存大约可慢到1000多倍

FH

楼上真会纸上谈兵，全是课本上的理论，呵呵

superdoctor

[quote]原帖由 "FH"]楼上真会纸上谈兵，全是课本上的理论，呵呵[/quote 发表：


呵呵，有点，但也不全是

我当初在搞邮件的时候，起初采用mailbox格式－－就是一个用户所有的邮件都在一个文件中，每封邮件用分隔符区分（现在的linux/unix系统自带的邮件系统仍是这样），这样在当初邮件使用不频繁的时候给程序设计带来好处，但是在现在这样肯定不行，一个用户收取邮件的时候不得不将其整个的邮件文件（有可能几个G）吞入内存，造成性能很低，所以后来都改用maildir的格式，就是每个用户一个目录，每封邮件单独一个文件，这样就大大缓解了系统资源的争用，我想，这应该算是一个"纸下谈兵"的例子吧，FH

FH

楼上的例子不说明别的，只说明你的程序没设计好，因为根本不需要将整个文件读进内存！
你可以将邮件文件设计成长度＋内容＋长度＋内容……的形式，每次读长度，然后跳过内容，再读长度……这需要很大的开销么？
即使用分割符分割，也没必要一次把数据全读进来啊，可以读一段处理一段嘛！我曾经见过不少的新手将文件一次全部读进内存，然后简单地用字符串函数进行处理，还人为地添加上文件大小的限制，这只能说明非懒即笨，不肯多动动脑筋或多动动手。
我曾经对整个8G的数据文件逐条记录（不定长）分析，根据数据类型分解成4个分类文件，没用多长时间，更没消耗多少系统资源。
所以说，事在人为，有些理论上的东西关键看你怎么规避和利用，任何东西都不是绝对的。

superdoctor

说的是不错，但是我想所谓的操作一个大文件不仅仅是读那么简单吧，就拿我的那个例子，在一个大邮件文件中，可能我想删除其中的分隔几端，那么FH认为到底那种效率高呢？

njmpop

在64位系统上没有问题。

在32位系统上考虑fpos64_t吧。fopen64？都有对应的函数。当然可能需要更改系统。随不同的系统不同吧。

njmpop

真有这种需求？很怀疑。。

使用索引？100g？如果不是dvd的话，那这个索引也得不小.
不如做个多重索引，岂不是速度更快？

我倒是挺赞成superdoctor，还是使用fopen吧，移植也方便。

superdoctor

原帖由 "njmpop" 发表：
在64位系统上没有问题。

在32位系统上考虑fpos64_t吧。fopen64？都有对应的函数。当然可能需要更改系统。随不同的系统不同吧。

我觉得64位系统下开发软件是必须要考虑单个文本文件大小的，100G不管技术上可不可行，但都是设计上不足取的，难道为了更快的处理还需要为其设计一个索引文件不成么？

100G我估计就是索引也够大了吧

而且采用多层hash的方式分离单个文件，不仅从程序设计上更加健壮、简洁，而且速度是其主要的优势