Lines Matching refs:to

4 This target takes 2 devices, one to pass all IO to normally, and one to log all
5 of the write operations to.  This is intended for file system developers wishing
6 to verify the integrity of metadata or data as the file system is written to.
8 able to take arbitrary data from userspace to insert into the log.  The data
9 that is in the WRITE requests is copied into the log to make the replay happen
17 next REQ_FLUSH request.  This is to make it easier for userspace to replay the
18 log in a way that correlates to what is on disk and not what is in cache, to
19 make it easier to detect improper waiting/flushing.
21 This works by attaching all WRITE requests to a list once the write completes.
24 completed WRITEs, at the time the REQ_FLUSH is issued, are added in order to
25 simulate the worst case scenario with regard to power failures.  Consider the
34 Again this is to simulate what is actually on disk, this allows us to detect
60    dev_path	: Device that all of the IO will go to normally.
61    log_dev_path : Device where the log entries are written to.
74 	You can use a dmsetup message to set an arbitrary mark in a log.
75 	For example say you want to fsck a file system after every
76 	write, but first you need to replay up to the mkfs to make sure
84 	  This would allow you to replay the log up to the mkfs mark and
99 Say you want to test fsync on your file system.  You would do something like
119 Another option is to do a complicated file system operation and verify the file
128 <fsstress to dirty the fs>
139 and if the fsck passes it will replay to the next FUA, until it is completed or