summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authormcsim <mcsim@web>2011-11-24 23:20:31 +0100
committerGNU Hurd web pages engine <web-hurd@gnu.org>2011-11-24 23:20:31 +0100
commite6aabed5cb7a1d5f5d472a36c9f4c5802ae95fc8 (patch)
tree2a0005799b9d321f22b8bffd86ec93cdfba26211
parent7c71157c69d769c007c02fc991dad2c1f519b5c5 (diff)
-rw-r--r--user/Maksym_Planeta.mdwn31
1 files changed, 30 insertions, 1 deletions
diff --git a/user/Maksym_Planeta.mdwn b/user/Maksym_Planeta.mdwn
index 3c330388..1c589ed8 100644
--- a/user/Maksym_Planeta.mdwn
+++ b/user/Maksym_Planeta.mdwn
@@ -7,7 +7,7 @@ any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
-
+
[[!toc]]
#Notes on tmpfs
@@ -36,6 +36,17 @@ Probably pager_request shouldn't be stored because request may arrive from diffe
22.11.11 Reading/writing for any size works, [[this|http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00127.html]] works, but fsx test fails ([[see|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#fsx_fail2211]]).
+24.11.11 The problem with fsx.
+
+Here are follow operations:
+
+1. Write some data at address 0x100 with size 0x20
+2. Truncate file to size 0x80. First written data should be lost.
+3. Write some data at address 0x200 size of 0x20. By this operation file size is increased up to 0x220.
+4. Read data at address 0x110. Fsx expects here zeros, but in fact here is data, that was written at step 1.
+
+When fsx tries to read data kernel calls pager with seqno_memory_object_data_request, and pager returns on step 4 zeros either with memory_object_data_provided or memory_object_data_unavailable. Before this, in default_pager_set_size memory_object_lock_request called to flush any kernel caches, that could hold data to be truncated. When I set offset to 0 and size to limit in memory_object_lock_request it appeared another error ([[see|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#fsx_fail2411]]). Both these behaviors appear to be quite strange for me. It is quite late now, so i put these notes to not forget this and went sleep. Continue tomorrow.
+
### Write own pager
6.11.11 Reading/writing for files that fit in vm_page_size works
@@ -210,3 +221,21 @@ For debugging ext2fs:
16(16 mod 256): READ 0x16000 thru 0x2399f (0xd9a0 bytes) ***RRRR***
Correct content saved for comparison
(maybe hexdump "bar" vs "bar.fsxgood")
+
+## fsx test on 24.11.11 <a id="fsx_fail2411"/>
+
+ $ ~/src/fsx/fsx bar
+ truncating to largest ever: 0x13e76
+ READ BAD DATA: offset = 0x1f62e, size = 0x2152
+ OFFSET GOOD BAD RANGE
+ 0x1f62e 0x0206 0x0000 0x 213e
+ operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops
+ LOG DUMP (6 total operations):
+ 1(1 mod 256): TRUNCATE UP from 0x0 to 0x13e76
+ 2(2 mod 256): WRITE 0x17098 thru 0x26857 (0xf7c0 bytes) HOLE ***WWWW
+ 3(3 mod 256): READ 0xc73e thru 0x1b801 (0xf0c4 bytes)
+ 4(4 mod 256): MAPWRITE 0x32e00 thru 0x331fc (0x3fd bytes)
+ 5(5 mod 256): MAPWRITE 0x7ac1 thru 0x11029 (0x9569 bytes)
+ 6(6 mod 256): READ 0x1f62e thru 0x2177f (0x2152 bytes) ***RRRR***
+ Correct content saved for comparison
+ (maybe hexdump "bar" vs "bar.fsxgood")