mirror of
https://github.com/amadvance/snapraid.git
synced 2026-10-26 19:01:57 -04:00
Some comments about the use of posix_advise().
This commit is contained in:
parent
81f14d1dfb
commit
637789d11b
3 changed files with 20 additions and 3 deletions
1
HISTORY
1
HISTORY
|
|
@ -3,6 +3,7 @@ SnapRAID HISTORY
|
|||
|
||||
0.3 2011/4
|
||||
==========
|
||||
* Better ETA estimation.
|
||||
* Added support for OpenSSL crypto library to use its optimized MD5 implementation.
|
||||
* Added test vector for MD5.
|
||||
* Added a speed test option for MD5.
|
||||
|
|
|
|||
8
handle.c
8
handle.c
|
|
@ -256,6 +256,11 @@ int handle_read(struct snapraid_handle* handle, struct snapraid_block* block, un
|
|||
return -1;
|
||||
}
|
||||
|
||||
/* Here isn't needed to call posix_fadvise(..., POSIX_FADV_DONTNEED) because */
|
||||
/* we already advised sequential access with POSIX_FADV_SEQUENTIAL. */
|
||||
/* In Linux 2.6.33 it's enough to ensure that data is not kept in the cache. */
|
||||
/* Better to do nothing and save a syscall for each block. */
|
||||
|
||||
return read_size;
|
||||
}
|
||||
|
||||
|
|
@ -284,6 +289,9 @@ int handle_write(struct snapraid_handle* handle, struct snapraid_block* block, u
|
|||
return -1;
|
||||
}
|
||||
|
||||
/* Here doesn't make sense to call posix_fadvise(..., POSIX_FADV_DONTNEED) because */
|
||||
/* at this time the data is still in not yet written and it cannot be discharged. */
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
|
|||
14
parity.c
14
parity.c
|
|
@ -143,9 +143,9 @@ int parity_sync(const char* path, int f)
|
|||
#if HAVE_FSYNC
|
||||
int ret;
|
||||
|
||||
/* ensure that data changes are written to disk */
|
||||
/* this is required to ensure that parity is more updated than content */
|
||||
/* in case of a system crash */
|
||||
/* Ensure that data changes are written to disk. */
|
||||
/* This is required to ensure that parity is more updated than content */
|
||||
/* in case of a system crash. */
|
||||
ret = fsync(f);
|
||||
if (ret != 0) {
|
||||
fprintf(stderr, "Error synching parity file '%s'. %s.\n", path, strerror(errno));
|
||||
|
|
@ -202,6 +202,9 @@ int parity_write(const char* path, int f, block_off_t pos, unsigned char* block_
|
|||
return -1;
|
||||
}
|
||||
|
||||
/* Here doesn't make sense to call posix_fadvise(..., POSIX_FADV_DONTNEED) because */
|
||||
/* at this time the data is still in not yet written and it cannot be discharged. */
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
@ -227,6 +230,11 @@ int parity_read(const char* path, int f, block_off_t pos, unsigned char* block_b
|
|||
return -1;
|
||||
}
|
||||
|
||||
/* Here isn't needed to call posix_fadvise(..., POSIX_FADV_DONTNEED) because */
|
||||
/* we already advised sequential access with POSIX_FADV_SEQUENTIAL. */
|
||||
/* In Linux 2.6.33 it's enough to ensure that data is not kept in the cache. */
|
||||
/* Better to do nothing and save a syscall for each block. */
|
||||
|
||||
return block_size;
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue