2012-11-29 13:28:09 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-16 11:13:04 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2013-02-04 23:41:41 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-04-28 18:12:36 +09:00
|
|
|
|
2015-04-20 15:19:06 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
2014-12-17 20:04:08 -08:00
|
|
|
|
2013-04-20 01:28:40 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
f2fs: use rw_sem instead of fs_lock(locks mutex)
The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
And each other operate routine(besides checkpoint) needs to acquire a fs_lock,
there is a terrible problem here, if these are too many concurrency threads acquiring
fs_lock, so that they will block each other and may lead to some performance problem,
but this is not the phenomenon we want to see.
Though there are some optimization patches introduced to enhance the usage of fs_lock,
but the thorough solution is using a *rw_sem* to replace the fs_lock.
Checkpoint routine takes write_sem, and other ops take read_sem, so that we can block
other ops(ex, recovery) when doing checkpoint, and other ops will not disturb each other,
this can avoid the problem described above completely.
Because of the weakness of rw_sem, the above change may introduce a potential problem
that the checkpoint thread might get starved if other threads are intensively locking
the read semaphore for I/O.(Pointed out by Xu Jin)
In order to avoid this, a wait_list is introduced, the appending read semaphore ops
will be dropped into the wait_list if checkpoint thread is waiting for write semaphore,
and will be waked up when checkpoint thread gives up write semaphore.
Thanks to Kim's previous review and test, and will be very glad to see other guys'
performance tests about this patch.
V2:
-fix the potential starvation problem.
-use more suitable func name suggested by Xu Jin.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
[Jaegeuk Kim: adjust minor coding standard]
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-09-27 18:08:30 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
2014-08-07 16:32:25 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
f2fs: use rw_sem instead of fs_lock(locks mutex)
The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
And each other operate routine(besides checkpoint) needs to acquire a fs_lock,
there is a terrible problem here, if these are too many concurrency threads acquiring
fs_lock, so that they will block each other and may lead to some performance problem,
but this is not the phenomenon we want to see.
Though there are some optimization patches introduced to enhance the usage of fs_lock,
but the thorough solution is using a *rw_sem* to replace the fs_lock.
Checkpoint routine takes write_sem, and other ops take read_sem, so that we can block
other ops(ex, recovery) when doing checkpoint, and other ops will not disturb each other,
this can avoid the problem described above completely.
Because of the weakness of rw_sem, the above change may introduce a potential problem
that the checkpoint thread might get starved if other threads are intensively locking
the read semaphore for I/O.(Pointed out by Xu Jin)
In order to avoid this, a wait_list is introduced, the appending read semaphore ops
will be dropped into the wait_list if checkpoint thread is waiting for write semaphore,
and will be waked up when checkpoint thread gives up write semaphore.
Thanks to Kim's previous review and test, and will be very glad to see other guys'
performance tests about this patch.
V2:
-fix the potential starvation problem.
-use more suitable func name suggested by Xu Jin.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
[Jaegeuk Kim: adjust minor coding standard]
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-09-27 18:08:30 +08:00
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2014-10-17 20:33:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-04-28 09:04:18 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-12-06 15:00:58 +09:00
|
|
|
|
2013-04-28 09:04:18 +09:00
|
|
|
|
2013-12-06 15:00:58 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-28 09:04:18 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2015-09-11 14:43:52 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-25 14:26:31 +09:00
|
|
|
|
2013-04-28 09:04:18 +09:00
|
|
|
|
|
|
|
|
|
2014-03-18 13:29:07 +09:00
|
|
|
|
2015-10-08 13:27:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-13 17:43:19 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 18:37:41 +09:00
|
|
|
|
2014-04-07 15:37:19 -07:00
|
|
|
|
2013-01-17 18:37:41 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2013-06-14 08:52:35 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-29 17:02:18 -07:00
|
|
|
|
2013-07-22 22:12:56 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-14 08:52:35 +09:00
|
|
|
|
2013-07-22 22:12:56 +09:00
|
|
|
|
|
|
|
|
|
2013-06-14 08:52:35 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-20 18:37:35 +08:00
|
|
|
|
|
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2014-08-20 18:37:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-29 17:02:18 -07:00
|
|
|
|
|
|
|
|
|
2014-08-20 18:37:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-30 22:47:03 -07:00
|
|
|
|
|
|
|
|
|
2014-11-05 20:05:53 -08:00
|
|
|
|
|
|
|
|
|
2014-08-20 18:37:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-08 15:29:40 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-08 15:29:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-20 19:10:08 +09:00
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2014-09-10 14:58:18 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 11:28:40 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-06 15:00:58 +09:00
|
|
|
|
2012-12-01 10:56:01 +09:00
|
|
|
|
|
|
|
|
|
2013-04-20 01:28:40 +09:00
|
|
|
|
2014-07-24 19:11:43 -07:00
|
|
|
|
|
|
|
|
|
2014-09-10 16:53:02 -07:00
|
|
|
|
2014-07-24 19:11:43 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-09-10 16:53:02 -07:00
|
|
|
|
|
|
|
|
|
2013-04-20 01:28:40 +09:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-04-20 01:28:40 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-12-08 15:29:40 +09:00
|
|
|
|
2015-08-15 21:51:05 -07:00
|
|
|
|
|
|
|
|
|
2014-12-08 15:29:40 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-24 19:08:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-10 14:58:18 -07:00
|
|
|
|
2014-09-10 15:04:03 -07:00
|
|
|
|
2014-12-08 15:29:40 +09:00
|
|
|
|
|
|
|
|
|
2014-09-10 15:04:03 -07:00
|
|
|
|
|
|
|
|
|
2014-07-24 19:08:02 -07:00
|
|
|
|
2014-09-10 14:58:18 -07:00
|
|
|
|
2014-07-24 19:08:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-10 15:04:03 -07:00
|
|
|
|
2013-01-11 13:10:49 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-03 10:55:52 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-20 18:37:35 +08:00
|
|
|
|
|
|
|
|
|
2014-03-20 19:10:08 +09:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-20 19:10:08 +09:00
|
|
|
|
2014-12-08 15:29:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-02 10:48:56 -08:00
|
|
|
|
|
|
|
|
|
2014-12-08 15:29:41 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-12-08 15:29:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-09 16:27:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-08 15:29:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-04-20 01:28:40 +09:00
|
|
|
|
2015-04-23 14:38:15 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 18:12:36 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-30 17:25:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 18:12:36 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 18:12:36 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-24 18:19:10 +08:00
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 18:12:36 +09:00
|
|
|
|
|
|
|
|
|
2015-09-11 14:43:52 +08:00
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-06 23:22:50 +09:00
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-07 11:21:59 +08:00
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
f2fs: avoid data offset overflow when lseeking huge file
xfstest generic/285 complains our issue in lseeking huge file.
Here is the detail output of generic/285:
"./check -f2fs tests/generic/285
Ran: generic/285
Failures: generic/285
Failed 1 of 1 tests
10. Test a huge file for offset overflow
10.01 SEEK_HOLE expected 65536 or 8589934592, got 65536. succ
10.02 SEEK_HOLE expected 65536 or 8589934592, got 65536. succ
10.03 SEEK_DATA expected 0 or 0, got 0. succ
10.04 SEEK_DATA expected 1 or 1, got 1. succ
10.05 SEEK_HOLE expected 8589934592 or 8589934592, got 0. FAIL
10.06 SEEK_DATA expected 8589869056 or 8589869056, got 8589869056. succ
10.07 SEEK_DATA expected 8589869057 or 8589869057, got 8589869057. succ
10.08 SEEK_DATA expected 8589869056 or 8589869056, got 4294901760. FAIL"
The reason of this issue is:
We will calculate current offset through left shifting page-offset with
PAGE_CACHE_SHIFT bits, but our page-offset is a type of unsigned long, its size
is 4 bytes in 32-bits machine.
So if our page-offset is bigger than (1 << 32 / pagesize - 1), result of left
shifting will overflow.
Let's fix this issue by casting type of page-offset to type of current offset:
loff_t.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2015-02-09 11:23:58 +08:00
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 18:12:36 +09:00
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 17:02:48 +09:00
|
|
|
|
|
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-08 10:59:43 -07:00
|
|
|
|
|
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
2015-04-21 20:39:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-21 20:39:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-22 08:02:02 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
f2fs: update extent tree in batches
This patch introduce a new helper f2fs_update_extent_tree_range which can
do extent mapping update at a specified range.
The main idea is:
1) punch all mapping info in extent node(s) which are at a specified range;
2) try to merge new extent mapping with adjacent node, or failing that,
insert the mapping into extent tree as a new node.
In order to see the benefit, I add a function for stating time stamping
count as below:
uint64_t rdtsc(void)
{
uint32_t lo, hi;
__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
return (uint64_t)hi << 32 | lo;
}
My test environment is: ubuntu, intel i7-3770, 16G memory, 256g micron ssd.
truncation path: update extent cache from truncate_data_blocks_range
non-truncataion path: update extent cache from other paths
total: all update paths
a) Removing 128MB file which has one extent node mapping whole range of
file:
1. dd if=/dev/zero of=/mnt/f2fs/128M bs=1M count=128
2. sync
3. rm /mnt/f2fs/128M
Before:
total count average
truncation: 7651022 32768 233.49
Patched:
total count average
truncation: 3321 33 100.64
b) fsstress:
fsstress -d /mnt/f2fs -l 5 -n 100 -p 20
Test times: 5 times.
Before:
total count average
truncation: 5812480.6 20911.6 277.95
non-truncation: 7783845.6 13440.8 579.12
total: 13596326.2 34352.4 395.79
Patched:
total count average
truncation: 1281283.0 3041.6 421.25
non-truncation: 7355844.4 13662.8 538.38
total: 8637127.4 16704.4 517.06
1) For the updates in truncation path:
- we can see updating in batches leads total tsc and update count reducing
explicitly;
- besides, for a single batched updating, punching multiple extent nodes
in a loop, result in executing more operations, so our average tsc
increase intensively.
2) For the updates in non-truncation path:
- there is a little improvement, that is because for the scenario that we
just need to update in the head or tail of extent node, new interface
optimize to update info in extent node directly, rather than removing
original extent node for updating and then inserting that updated one
into cache as new node.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2015-08-26 20:34:48 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2013-07-15 17:57:38 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-01-17 14:44:39 -06:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-30 22:57:55 -08:00
|
|
|
|
2015-03-19 19:23:32 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-03-17 17:16:35 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
f2fs: update extent tree in batches
This patch introduce a new helper f2fs_update_extent_tree_range which can
do extent mapping update at a specified range.
The main idea is:
1) punch all mapping info in extent node(s) which are at a specified range;
2) try to merge new extent mapping with adjacent node, or failing that,
insert the mapping into extent tree as a new node.
In order to see the benefit, I add a function for stating time stamping
count as below:
uint64_t rdtsc(void)
{
uint32_t lo, hi;
__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
return (uint64_t)hi << 32 | lo;
}
My test environment is: ubuntu, intel i7-3770, 16G memory, 256g micron ssd.
truncation path: update extent cache from truncate_data_blocks_range
non-truncataion path: update extent cache from other paths
total: all update paths
a) Removing 128MB file which has one extent node mapping whole range of
file:
1. dd if=/dev/zero of=/mnt/f2fs/128M bs=1M count=128
2. sync
3. rm /mnt/f2fs/128M
Before:
total count average
truncation: 7651022 32768 233.49
Patched:
total count average
truncation: 3321 33 100.64
b) fsstress:
fsstress -d /mnt/f2fs -l 5 -n 100 -p 20
Test times: 5 times.
Before:
total count average
truncation: 5812480.6 20911.6 277.95
non-truncation: 7783845.6 13440.8 579.12
total: 13596326.2 34352.4 395.79
Patched:
total count average
truncation: 1281283.0 3041.6 421.25
non-truncation: 7355844.4 13662.8 538.38
total: 8637127.4 16704.4 517.06
1) For the updates in truncation path:
- we can see updating in batches leads total tsc and update count reducing
explicitly;
- besides, for a single batched updating, punching multiple extent nodes
in a loop, result in executing more operations, so our average tsc
increase intensively.
2) For the updates in non-truncation path:
- there is a little improvement, that is because for the scenario that we
just need to update in the head or tail of extent node, new interface
optimize to update info in extent node directly, rather than removing
original extent node for updating and then inserting that updated one
into cache as new node.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2015-08-26 20:34:48 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
f2fs: update extent tree in batches
This patch introduce a new helper f2fs_update_extent_tree_range which can
do extent mapping update at a specified range.
The main idea is:
1) punch all mapping info in extent node(s) which are at a specified range;
2) try to merge new extent mapping with adjacent node, or failing that,
insert the mapping into extent tree as a new node.
In order to see the benefit, I add a function for stating time stamping
count as below:
uint64_t rdtsc(void)
{
uint32_t lo, hi;
__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
return (uint64_t)hi << 32 | lo;
}
My test environment is: ubuntu, intel i7-3770, 16G memory, 256g micron ssd.
truncation path: update extent cache from truncate_data_blocks_range
non-truncataion path: update extent cache from other paths
total: all update paths
a) Removing 128MB file which has one extent node mapping whole range of
file:
1. dd if=/dev/zero of=/mnt/f2fs/128M bs=1M count=128
2. sync
3. rm /mnt/f2fs/128M
Before:
total count average
truncation: 7651022 32768 233.49
Patched:
total count average
truncation: 3321 33 100.64
b) fsstress:
fsstress -d /mnt/f2fs -l 5 -n 100 -p 20
Test times: 5 times.
Before:
total count average
truncation: 5812480.6 20911.6 277.95
non-truncation: 7783845.6 13440.8 579.12
total: 13596326.2 34352.4 395.79
Patched:
total count average
truncation: 1281283.0 3041.6 421.25
non-truncation: 7355844.4 13662.8 538.38
total: 8637127.4 16704.4 517.06
1) For the updates in truncation path:
- we can see updating in batches leads total tsc and update count reducing
explicitly;
- besides, for a single batched updating, punching multiple extent nodes
in a loop, result in executing more operations, so our average tsc
increase intensively.
2) For the updates in non-truncation path:
- there is a little improvement, that is because for the scenario that we
just need to update in the head or tail of extent node, new interface
optimize to update info in extent node directly, rather than removing
original extent node for updating and then inserting that updated one
into cache as new node.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2015-08-26 20:34:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-08 21:25:40 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-20 01:28:52 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-10 13:16:25 +08:00
|
|
|
|
2015-04-30 17:00:33 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2015-04-30 17:00:33 -07:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2015-04-30 17:00:33 -07:00
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-04-30 17:00:33 -07:00
|
|
|
|
2015-10-09 15:11:38 -07:00
|
|
|
|
2015-04-30 17:00:33 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-09 15:11:38 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2015-04-30 17:00:33 -07:00
|
|
|
|
2014-03-18 13:29:07 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-04-23 12:04:33 -07:00
|
|
|
|
2015-03-10 13:16:25 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-08-14 16:32:54 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
f2fs: handle inline data operations
Hook inline data read/write, truncate, fallocate, setattr, etc.
Files need meet following 2 requirement to inline:
1) file size is not greater than MAX_INLINE_DATA;
2) file doesn't pre-allocate data blocks by fallocate().
FI_INLINE_DATA will not be set while creating a new regular inode because
most of the files are bigger than ~3.4K. Set FI_INLINE_DATA only when
data is submitted to block layer, ranther than set it while creating a new
inode, this also avoids converting data from inline to normal data block
and vice versa.
While writting inline data to inode block, the first data block should be
released if the file has a block indexed by i_addr[0].
On the other hand, when a file operation is appied to a file with inline
data, we need to test if this file can remain inline by doing this
operation, otherwise it should be convert into normal file by reserving
a new data block, copying inline data to this new block and clear
FI_INLINE_DATA flag. Because reserve a new data block here will make use
of i_addr[0], if we save inline data in i_addr[0..872], then the first
4 bytes would be overwriten. This problem can be avoided simply by
not using i_addr[0] for inline data.
Signed-off-by: Huajun Li <huajun.li@intel.com>
Signed-off-by: Haicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: Weihong Xu <weihong.xu@intel.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-11-10 23:13:20 +08:00
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2015-03-10 13:16:25 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-04-20 01:28:52 +09:00
|
|
|
|
|
|
|
|
|
2015-02-09 12:02:44 -08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-08-14 16:32:54 -07:00
|
|
|
|
|
|
|
|
|
f2fs: handle inline data operations
Hook inline data read/write, truncate, fallocate, setattr, etc.
Files need meet following 2 requirement to inline:
1) file size is not greater than MAX_INLINE_DATA;
2) file doesn't pre-allocate data blocks by fallocate().
FI_INLINE_DATA will not be set while creating a new regular inode because
most of the files are bigger than ~3.4K. Set FI_INLINE_DATA only when
data is submitted to block layer, ranther than set it while creating a new
inode, this also avoids converting data from inline to normal data block
and vice versa.
While writting inline data to inode block, the first data block should be
released if the file has a block indexed by i_addr[0].
On the other hand, when a file operation is appied to a file with inline
data, we need to test if this file can remain inline by doing this
operation, otherwise it should be convert into normal file by reserving
a new data block, copying inline data to this new block and clear
FI_INLINE_DATA flag. Because reserve a new data block here will make use
of i_addr[0], if we save inline data in i_addr[0..872], then the first
4 bytes would be overwriten. This problem can be avoided simply by
not using i_addr[0] for inline data.
Signed-off-by: Huajun Li <huajun.li@intel.com>
Signed-off-by: Haicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: Weihong Xu <weihong.xu@intel.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-11-10 23:13:20 +08:00
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-10 13:16:25 +08:00
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2015-03-10 13:16:25 +08:00
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-26 13:10:46 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2014-10-15 10:24:34 -07:00
|
|
|
|
|
|
|
|
|
2014-04-26 19:59:52 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-09-02 15:52:58 -07:00
|
|
|
|
f2fs: introduce a new global lock scheme
In the previous version, f2fs uses global locks according to the usage types,
such as directory operations, block allocation, block write, and so on.
Reference the following lock types in f2fs.h.
enum lock_type {
RENAME, /* for renaming operations */
DENTRY_OPS, /* for directory operations */
DATA_WRITE, /* for data write */
DATA_NEW, /* for data allocation */
DATA_TRUNC, /* for data truncate */
NODE_NEW, /* for node allocation */
NODE_TRUNC, /* for node truncate */
NODE_WRITE, /* for node write */
NR_LOCK_TYPE,
};
In that case, we lose the performance under the multi-threading environment,
since every types of operations must be conducted one at a time.
In order to address the problem, let's share the locks globally with a mutex
array regardless of any types.
So, let users grab a mutex and perform their jobs in parallel as much as
possbile.
For this, I propose a new global lock scheme as follows.
0. Data structure
- f2fs_sb_info -> mutex_lock[NR_GLOBAL_LOCKS]
- f2fs_sb_info -> node_write
1. mutex_lock_op(sbi)
- try to get an avaiable lock from the array.
- returns the index of the gottern lock variable.
2. mutex_unlock_op(sbi, index of the lock)
- unlock the given index of the lock.
3. mutex_lock_all(sbi)
- grab all the locks in the array before the checkpoint.
4. mutex_unlock_all(sbi)
- release all the locks in the array after checkpoint.
5. block_operations()
- call mutex_lock_all()
- sync_dirty_dir_inodes()
- grab node_write
- sync_node_pages()
Note that,
the pairs of mutex_lock_op()/mutex_unlock_op() and
mutex_lock_all()/mutex_unlock_all() should be used together.
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2012-11-22 16:21:29 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 11:01:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-10 13:16:25 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-04-20 01:28:52 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 17:39:42 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-08-24 17:39:42 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2015-08-24 17:39:42 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-04-20 01:28:52 +09:00
|
|
|
|
|
|
|
|
|
2014-11-11 14:10:01 -08:00
|
|
|
|
2015-04-23 10:27:21 -07:00
|
|
|
|
2015-08-24 17:39:42 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 14:10:01 -08:00
|
|
|
|
|
|
|
|
|
2015-08-24 17:39:42 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2013-06-07 16:33:07 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2015-03-17 22:25:59 +00:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-17 22:25:59 +00:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-15 18:02:09 +08:00
|
|
|
|
2015-04-21 20:39:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-05 18:34:02 +08:00
|
|
|
|
2014-09-15 18:02:09 +08:00
|
|
|
|
2015-08-24 17:39:42 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-15 18:02:09 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-05 18:34:02 +08:00
|
|
|
|
|
|
|
|
|
2014-09-15 18:02:09 +08:00
|
|
|
|
2015-06-05 18:34:02 +08:00
|
|
|
|
2015-09-28 17:46:01 +08:00
|
|
|
|
2014-09-15 18:02:09 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-20 05:16:45 -08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-20 05:16:45 -08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-08 04:30:14 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-01-25 18:33:41 +09:00
|
|
|
|
|
|
|
|
|
f2fs: use rw_sem instead of fs_lock(locks mutex)
The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
And each other operate routine(besides checkpoint) needs to acquire a fs_lock,
there is a terrible problem here, if these are too many concurrency threads acquiring
fs_lock, so that they will block each other and may lead to some performance problem,
but this is not the phenomenon we want to see.
Though there are some optimization patches introduced to enhance the usage of fs_lock,
but the thorough solution is using a *rw_sem* to replace the fs_lock.
Checkpoint routine takes write_sem, and other ops take read_sem, so that we can block
other ops(ex, recovery) when doing checkpoint, and other ops will not disturb each other,
this can avoid the problem described above completely.
Because of the weakness of rw_sem, the above change may introduce a potential problem
that the checkpoint thread might get starved if other threads are intensively locking
the read semaphore for I/O.(Pointed out by Xu Jin)
In order to avoid this, a wait_list is introduced, the appending read semaphore ops
will be dropped into the wait_list if checkpoint thread is waiting for write semaphore,
and will be waked up when checkpoint thread gives up write semaphore.
Thanks to Kim's previous review and test, and will be very glad to see other guys'
performance tests about this patch.
V2:
-fix the potential starvation problem.
-use more suitable func name suggested by Xu Jin.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
[Jaegeuk Kim: adjust minor coding standard]
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-09-27 18:08:30 +08:00
|
|
|
|
2013-05-20 09:55:50 +09:00
|
|
|
|
f2fs: use rw_sem instead of fs_lock(locks mutex)
The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
And each other operate routine(besides checkpoint) needs to acquire a fs_lock,
there is a terrible problem here, if these are too many concurrency threads acquiring
fs_lock, so that they will block each other and may lead to some performance problem,
but this is not the phenomenon we want to see.
Though there are some optimization patches introduced to enhance the usage of fs_lock,
but the thorough solution is using a *rw_sem* to replace the fs_lock.
Checkpoint routine takes write_sem, and other ops take read_sem, so that we can block
other ops(ex, recovery) when doing checkpoint, and other ops will not disturb each other,
this can avoid the problem described above completely.
Because of the weakness of rw_sem, the above change may introduce a potential problem
that the checkpoint thread might get starved if other threads are intensively locking
the read semaphore for I/O.(Pointed out by Xu Jin)
In order to avoid this, a wait_list is introduced, the appending read semaphore ops
will be dropped into the wait_list if checkpoint thread is waiting for write semaphore,
and will be waked up when checkpoint thread gives up write semaphore.
Thanks to Kim's previous review and test, and will be very glad to see other guys'
performance tests about this patch.
V2:
-fix the potential starvation problem.
-use more suitable func name suggested by Xu Jin.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
[Jaegeuk Kim: adjust minor coding standard]
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-09-27 18:08:30 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-17 20:22:44 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-09-17 20:22:44 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2015-09-17 20:22:44 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-09-17 20:22:44 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-09-17 20:22:44 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-17 20:22:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-09-17 20:22:44 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 16:52:50 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
f2fs: handle inline data operations
Hook inline data read/write, truncate, fallocate, setattr, etc.
Files need meet following 2 requirement to inline:
1) file size is not greater than MAX_INLINE_DATA;
2) file doesn't pre-allocate data blocks by fallocate().
FI_INLINE_DATA will not be set while creating a new regular inode because
most of the files are bigger than ~3.4K. Set FI_INLINE_DATA only when
data is submitted to block layer, ranther than set it while creating a new
inode, this also avoids converting data from inline to normal data block
and vice versa.
While writting inline data to inode block, the first data block should be
released if the file has a block indexed by i_addr[0].
On the other hand, when a file operation is appied to a file with inline
data, we need to test if this file can remain inline by doing this
operation, otherwise it should be convert into normal file by reserving
a new data block, copying inline data to this new block and clear
FI_INLINE_DATA flag. Because reserve a new data block here will make use
of i_addr[0], if we save inline data in i_addr[0..872], then the first
4 bytes would be overwriten. This problem can be avoided simply by
not using i_addr[0] for inline data.
Signed-off-by: Huajun Li <huajun.li@intel.com>
Signed-off-by: Haicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: Weihong Xu <weihong.xu@intel.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-11-10 23:13:20 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2013-04-08 20:16:44 -05:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-09-11 14:43:52 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
f2fs: introduce a new global lock scheme
In the previous version, f2fs uses global locks according to the usage types,
such as directory operations, block allocation, block write, and so on.
Reference the following lock types in f2fs.h.
enum lock_type {
RENAME, /* for renaming operations */
DENTRY_OPS, /* for directory operations */
DATA_WRITE, /* for data write */
DATA_NEW, /* for data allocation */
DATA_TRUNC, /* for data truncate */
NODE_NEW, /* for node allocation */
NODE_TRUNC, /* for node truncate */
NODE_WRITE, /* for node write */
NR_LOCK_TYPE,
};
In that case, we lose the performance under the multi-threading environment,
since every types of operations must be conducted one at a time.
In order to address the problem, let's share the locks globally with a mutex
array regardless of any types.
So, let users grab a mutex and perform their jobs in parallel as much as
possbile.
For this, I propose a new global lock scheme as follows.
0. Data structure
- f2fs_sb_info -> mutex_lock[NR_GLOBAL_LOCKS]
- f2fs_sb_info -> node_write
1. mutex_lock_op(sbi)
- try to get an avaiable lock from the array.
- returns the index of the gottern lock variable.
2. mutex_unlock_op(sbi, index of the lock)
- unlock the given index of the lock.
3. mutex_lock_all(sbi)
- grab all the locks in the array before the checkpoint.
4. mutex_unlock_all(sbi)
- release all the locks in the array after checkpoint.
5. block_operations()
- call mutex_lock_all()
- sync_dirty_dir_inodes()
- grab node_write
- sync_node_pages()
Note that,
the pairs of mutex_lock_op()/mutex_unlock_op() and
mutex_lock_all()/mutex_unlock_all() should be used together.
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2012-11-22 16:21:29 +09:00
|
|
|
|
f2fs: use rw_sem instead of fs_lock(locks mutex)
The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
And each other operate routine(besides checkpoint) needs to acquire a fs_lock,
there is a terrible problem here, if these are too many concurrency threads acquiring
fs_lock, so that they will block each other and may lead to some performance problem,
but this is not the phenomenon we want to see.
Though there are some optimization patches introduced to enhance the usage of fs_lock,
but the thorough solution is using a *rw_sem* to replace the fs_lock.
Checkpoint routine takes write_sem, and other ops take read_sem, so that we can block
other ops(ex, recovery) when doing checkpoint, and other ops will not disturb each other,
this can avoid the problem described above completely.
Because of the weakness of rw_sem, the above change may introduce a potential problem
that the checkpoint thread might get starved if other threads are intensively locking
the read semaphore for I/O.(Pointed out by Xu Jin)
In order to avoid this, a wait_list is introduced, the appending read semaphore ops
will be dropped into the wait_list if checkpoint thread is waiting for write semaphore,
and will be waked up when checkpoint thread gives up write semaphore.
Thanks to Kim's previous review and test, and will be very glad to see other guys'
performance tests about this patch.
V2:
-fix the potential starvation problem.
-use more suitable func name suggested by Xu Jin.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
[Jaegeuk Kim: adjust minor coding standard]
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-09-27 18:08:30 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
f2fs: use rw_sem instead of fs_lock(locks mutex)
The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
And each other operate routine(besides checkpoint) needs to acquire a fs_lock,
there is a terrible problem here, if these are too many concurrency threads acquiring
fs_lock, so that they will block each other and may lead to some performance problem,
but this is not the phenomenon we want to see.
Though there are some optimization patches introduced to enhance the usage of fs_lock,
but the thorough solution is using a *rw_sem* to replace the fs_lock.
Checkpoint routine takes write_sem, and other ops take read_sem, so that we can block
other ops(ex, recovery) when doing checkpoint, and other ops will not disturb each other,
this can avoid the problem described above completely.
Because of the weakness of rw_sem, the above change may introduce a potential problem
that the checkpoint thread might get starved if other threads are intensively locking
the read semaphore for I/O.(Pointed out by Xu Jin)
In order to avoid this, a wait_list is introduced, the appending read semaphore ops
will be dropped into the wait_list if checkpoint thread is waiting for write semaphore,
and will be waked up when checkpoint thread gives up write semaphore.
Thanks to Kim's previous review and test, and will be very glad to see other guys'
performance tests about this patch.
V2:
-fix the potential starvation problem.
-use more suitable func name suggested by Xu Jin.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
[Jaegeuk Kim: adjust minor coding standard]
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2013-09-27 18:08:30 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
|
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-09 15:11:38 -07:00
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
2015-07-16 18:18:11 +08:00
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
2015-07-16 18:18:11 +08:00
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
|
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-17 13:59:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-06 13:11:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-06 13:11:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-06 13:11:13 +08:00
|
|
|
|
2015-09-11 14:43:52 +08:00
|
|
|
|
2015-05-06 13:11:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-11 14:43:52 +08:00
|
|
|
|
2015-05-06 13:11:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-07 18:36:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-06 13:11:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-17 13:59:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
|
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
2015-10-07 12:28:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-02 15:31:18 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-04 10:11:17 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-27 12:28:59 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-13 13:05:55 +09:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-13 13:07:31 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-11-10 23:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-13 13:07:31 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-11 14:43:52 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-09-11 14:43:52 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-13 13:05:55 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-06-13 13:05:55 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2015-04-21 15:59:12 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-09-11 14:39:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
2015-04-21 20:39:58 -07:00
|
|
|
|
|
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-01-28 10:29:26 +08:00
|
|
|
|
|
|
|
|
|
2015-04-21 15:59:12 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 16:52:50 +08:00
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
|
|
|
|
|
2015-05-06 13:11:13 +08:00
|
|
|
|
|
|
|
|
|
2015-05-28 19:16:57 +08:00
|
|
|
|
|
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2015-05-06 13:09:46 +08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2012-12-30 14:52:37 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-28 10:29:26 +08:00
|
|
|
|
2015-04-21 15:59:12 +09:00
|
|
|
|
2014-01-28 10:29:26 +08:00
|
|
|
|
|
|
|
|
|
2013-04-23 17:00:52 +09:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-09 06:08:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-23 20:36:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 18:06:35 +08:00
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-09 06:08:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
2015-07-17 18:06:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
2015-07-17 18:06:35 +08:00
|
|
|
|
|
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 16:11:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-25 00:29:17 -07:00
|
|
|
|
|
|
|
|
|
2015-07-25 00:52:52 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-25 00:29:17 -07:00
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
2015-07-17 18:05:21 +08:00
|
|
|
|
2015-07-25 00:52:52 -07:00
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 16:11:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 18:06:35 +08:00
|
|
|
|
2014-10-06 16:11:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-09 06:08:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 18:06:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-23 19:48:09 -07:00
|
|
|
|
2015-07-17 18:06:35 +08:00
|
|
|
|
|
|
|
|
|
2014-10-06 16:11:16 -07:00
|
|
|
|
|
|
|
|
|
2014-12-09 06:08:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-17 17:16:35 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-06 08:28:46 -04:00
|
|
|
|
2014-12-09 06:08:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-21 18:49:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-08 17:51:10 -07:00
|
|
|
|
2014-12-09 06:08:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-08 19:15:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-07 09:46:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-08 19:15:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 15:19:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-08 13:28:03 +08:00
|
|
|
|
2015-04-20 15:19:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-05 22:22:44 +08:00
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-05 22:22:44 +08:00
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
|
|
|
|
|
2015-10-05 22:22:44 +08:00
|
|
|
|
|
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
2015-10-05 22:22:44 +08:00
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
2015-10-05 22:22:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
|
|
|
|
|
2015-10-05 22:22:44 +08:00
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
|
|
|
|
|
2015-10-05 22:24:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2013-06-08 21:25:28 +09:00
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
2013-06-08 21:25:28 +09:00
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
2015-01-23 20:36:04 +08:00
|
|
|
|
|
|
|
|
|
2014-10-06 17:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 16:11:16 -07:00
|
|
|
|
|
|
|
|
|
2014-12-09 06:08:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-08 19:15:53 -08:00
|
|
|
|
|
|
|
|
|
2014-09-20 22:06:39 -07:00
|
|
|
|
2014-09-24 15:37:02 -07:00
|
|
|
|
2015-04-20 15:19:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-10 18:08:10 +08:00
|
|
|
|
|
|
|
|
|
2015-10-05 22:24:19 +08:00
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-21 20:39:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-04 23:41:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-04-23 14:10:24 +08:00
|
|
|
|
2014-04-02 14:33:16 -04:00
|
|
|
|
2015-04-21 20:39:58 -07:00
|
|
|
|
|
|
|
|
|
2014-12-05 14:37:37 -08:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-04 23:41:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|
2014-04-05 04:27:08 -04:00
|
|
|
|
2012-11-02 17:09:44 +09:00
|
|
|
|