-1

I have a process let's say 'A' whose job is to copy three 4 GB files to a temporary file and then rename it by overwriting to an existing file. 'A' does this every 15 minutes. The CentOS version is 2.6.32-504.23.4

boost::filesystem::copy_file()
rename()

Now I am certain that the copy_file() takes only 5 seconds because I have the code to print timestamps. However what appears is that the overall operation together with rename() takes more than 3 minutes.

So my question is, at which point is the content of the file written to the disk from memory? I have not observed the copied file to have a zero size anytime. The ext4 mount is with default options. I also do not have any other calls like fsync() in between.

John Subas
  • 81
  • 1
  • 11

1 Answers1

0

24Gb transferred would take a SATA SSD no less than one minute and likely at least two, so as is obvious the three minute time is the true transfer time.

ext4 implements delayed allocation, so when you write new data to it it by default does nothing initially, and only gets around to allocating and writing out the data later at a time of its choosing.

ext4 also implements a hack which forces any delayed allocation to storage when you do a rename, i.e. an implicit fdatasync(). This hack became necessary because lots of code written for Linux doesn't pay attention to POSIX nor portability and was written to assume ext3 semantics. It therefore destroyed other people's data badly when ext4 loosened semantics from ext3. Due to the never ending complaints, they inserted the hack to make people shut up instead of forcing programmers to fix their code.

If you'd like more predictable behaviour, don't use ext4. It's better than ext3, but that's the only good thing I can say about it. Strongly consider XFS or even ZFS on Linux instead. They behave well, and according to POSIX and what all other Unix implementations do i.e. with much fewer quirks like you found.

Niall Douglas
  • 9,212
  • 2
  • 44
  • 54