<snip> > My understanding of "the way things are" by default, is that the OS > will buffer all writes until a certain point, then sync to disk. > So, first I started playing around with fsync() and fdatasync(). > These are supposed to be 2 different functions, with fdatasync() > supposedly being the faster of the two (since it only needs to > perform 1 write vs. fsync()'s 2). However, it seemed, at least on > Linux, that these 2 calls performed exactly the same. >
Well, the man page for fdatasync does in fact state that it is the same as fsync (under BUGS), however, that was for the 2.2 kernel. 2.4 may have fixed that. Have you tried using strace to see the actual system calls? <snip> > Someone mentioned to me that setvbuf() is "meant to be used on > streams, which is character based data, and in Linux, all devices are > block based" so I can't use setvbuf. Um, the way I read it from the man page, is that setvbuf is for streams, which is independent of the underlying disk system. Stream in this case means a FILE *, where data is buffered in a structure before write() is called to write the data. The OS may further buffer that data before writing it to disk in order to take advantage of other processes that are writing data in the same area of the disk. It is my understanding that fsync/fdatasync tells the OS to do it NOW. These functions have nothing to do with streams. By the way, did anybody know that glibc 2.2.x does intristic locking for stream based I/O? They added this to make the stream functions thread safe. It seems that this is the case even if your program doesn't use threads. There are a set of f*_unlocked functions where no locking is used. ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
