New answers tagged

2

rename is expected to be atomic: it either completes fully or not at all. Renaming A to take the place of B is supposed to leave you with either both A and B intact (it didn't happen at all); or with only A's contents under the name B (it completed fully). As long as the system doesn't crash, that'll happen regardless of fsync (etc.) calls. If the system ...


2

The code is legal but "naive". The problem is exactly that of what happens during a crash There's a potential risk that the new data won't have space allocated to it before the directory updates, and so runs the risk of a data loss. A good app will call fflush() and fsync() to ensure the data is flushed to disk. The auto_da_alloc routines are an ...


0

If is perfectly legal, it will work, but it will not do what you want. The 2nd is obvious. It destroys the original before saving the new. The 1st is less obvious, it looks like if there was a system fail (e.g. power outage), then you would ether have done nothing (not started); have 2 files: old and new; or succeeded. However this is not the case, unless ...


0

Since there is no better answer, I just wanted to remark that your values are very good for a flash drive in general, and quite within the expected range for your specific flash drive. Marketing values such as 190MB/s write speed are not in general sustainable (they are valid for a few seconds at most, till the internal buffer is filled,a nd do not reflect ...


0

For dd, setting the block size simply tells dd how many bytes to read in each read-store-output cycle. bs=nnn has no impact on filesystem block size, as dd operates on raw devices or binary files, treating input simply as a stream of bytes, and does not know about filesystems.



Top 50 recent answers are included