write(2) — Linux man page
write() writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd.
The number of bytes written may be less than count if, for example, there is insufficient space on the underlying physical medium, or the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or the call was interrupted by a signal handler after having written less than count bytes. (See also pipe(7).)
For a seekable file (i.e., one to which lseek(2) may be applied, for example, a regular file) writing takes place at the current file offset, and the file offset is incremented by the number of bytes actually written. If the file was open(2)ed with O_APPEND, the file offset is first set to the end of the file before writing. The adjustment of the file offset and the write operation are performed as an atomic step.
POSIX requires that a read(2) which can be proved to occur after a write() has returned returns the new data. Note that not all file systems are POSIX conforming.
Return Value
On success, the number of bytes written is returned (zero indicates nothing was written). On error, -1 is returned, and errno is set appropriately.
If count is zero and fd refers to a regular file, then write() may return a failure status if one of the errors below is detected. If no errors are detected, 0 will be returned without causing any other effect. If count is zero and fd refers to a file other than a regular file, the results are not specified.
Errors
EAGAIN The file descriptor fd refers to a file other than a socket and has been marked nonblocking (O_NONBLOCK), and the write would block. EAGAIN or EWOULDBLOCK The file descriptor fd refers to a socket and has been marked nonblocking (O_NONBLOCK), and the write would block. POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable application should check for both possibilities. EBADF fd is not a valid file descriptor or is not open for writing. EDESTADDRREQ fd refers to a datagram socket for which a peer address has not been set using connect(2). EDQUOT The user’s quota of disk blocks on the file system containing the file referred to by fd has been exhausted. EFAULT buf is outside your accessible address space. EFBIG An attempt was made to write a file that exceeds the implementation-defined maximum file size or the process’s file size limit, or to write at a position past the maximum allowed offset. EINTR The call was interrupted by a signal before any data was written; see signal(7). EINVAL fd is attached to an object which is unsuitable for writing; or the file was opened with the O_DIRECT flag, and either the address specified in buf, the value specified in count, or the current file offset is not suitably aligned. EIO A low-level I/O error occurred while modifying the inode. ENOSPC The device containing the file referred to by fd has no room for the data. EPIPE fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIGPIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)
Other errors may occur, depending on the object connected to fd.
Conforming to
Under SVr4 a write may be interrupted and return EINTR at any point, not just before any data is written.
Notes
A successful return from write() does not make any guarantee that data has been committed to disk. In fact, on some buggy implementations, it does not even guarantee that space has successfully been reserved for the data. The only way to be sure is to call fsync(2) after you are done writing all your data.
If a write() is interrupted by a signal handler before any bytes are written, then the call fails with the error EINTR; if it is interrupted after at least one byte has been written, the call succeeds, and returns the number of bytes written.
See Also
close(2), fcntl(2), fsync(2), ioctl(2), lseek(2), open(2), pwrite(2), read(2), select(2), writev(2), fwrite(3)
how to store a file in continuous disk block in linux
I want store some data on the disk in linux. I want this data stored in continuous disk block in physical disk. If i in order write this data to a normal file, maybe the block that the file occupies is not continuous in physical disk. Is there any way to do this job?
4 Answers 4
Disk partitions are continuous regions of a disk.
So one way to do what you want to do is to resize your disk partitions and create a new one with gparted (gnome) or partitionmanager (kde) or similiar — of an appropriate size for your file.
You can then write directly to your new partition (not using and bypassing a filesystem) by using the file:
Where sdxn = etc. is the letter/number of the partition.
Alternatively you can set aside an entire disk by writing directly to it (bypassing partition table alltogether) using the file:
Where sdx = etc. is the letter of the disk.
Warning: Don’t make a typo and write to the wrong one (that has a filesystem on it) or you will corrupt it. Best to make a symbolic link ln -s /dev/sdxn /home/fred/mydata, and then always write to mydata file.
The filesystem code (inside the kernel, e.g. in linux-3.1.6/fs/ext4/ for ext4 file systems inside the linux-3.1.6 kernel source) is managing the disk blocks used for a given file. So you cannot organize the disk blocks of some of your files by yourself. However, you might give some hints to the kernel using some weird system calls.
If you don’t like that, you could avoid the filesystem all together by writing directly to an unmounted partition, e.g. by doing write(2) syscalls to a file descriptor obtained by open(2)-ing for example /dev/sda2 ; but unless you really know what you are doing (and the formulation of your question makes me feel you don’t understand the exact role of file systems), I won’t recommend doing that.
Kernel file system code is quite good, and kernel file system cache is very efficient.
If you want to speed-up your reads, consider perhaps using readahead(2) or fadvise(2) or madvise(2) system calls.
You could also, when creating your filesystem, tune it for your particular purposes. For instance, if you know you’ll have mostly quite big files in it, you could use a bigger than standard block size (e.g. mke2fs -b 8192 ), etc.
But don’t think that software tricks would speed-up significantly your application; if you do a lot of disk IO, the real bottleneck is the hardware (so using SSD instead of hard disks might be easier).
Fastest way of writing a file to disk on Linux [closed]
It’s difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Suppose I have a very fast and infinite data source (say a socket, /dev/null or /dev/random) on Linux and I need to write such data to disk in C/C++. What’s the fastest code to accomplish that on a given hardware? fwrite(), unbuffered write(), some boost ASIO function?
1 Answer 1
Well in terms of raw output speed, then you’re going to have to benchmark it, depending on the test, QoI, platform, what you are writing and a hole host of other things any of FILE, fstreams or POSIX primitives can be the fastest.
However, if you can use something like Boost asio, then you might get a percieved speed up due to it’s asynchronous nature, it can get on with the next work read whilst it’s still writing to disk.
EDIT: I would go with boost asio, it will allow you to best utilise your resources whilst waiting for inherently slow operations (File and network IO).
Related
Hot Network Questions
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.