On 06/26/14 11:05, Vyacheslav Dubeyko wrote:
On Jun 26, 2014, at 9:00 AM, dE wrote:
Hi!
I'm using nilfs on thumb drives to sync Bitcoin wallets and it's forks.
Sometimes, when I quit the bitcoin-qt application, this is what happens (in dmesg)
[159141.505498] nilfs_btree_propagate: key = 10, level == 0
[159141.715622] nilfs_btree_propagate: key = 10, level == 0
[159141.716134] NILFS warning (device dm-0): nilfs_clean_segments: segment construction failed. (err=-2)
[159146.715145] nilfs_btree_propagate: key = 10, level == 0
[159146.715152] NILFS warning (device dm-0): nilfs_clean_segments: segment construction failed. (err=-2)
[159151.715018] nilfs_btree_propagate: key = 10, level == 0
[159151.715026] NILFS warning (device dm-0): nilfs_clean_segments: segment construction failed. (err=-2)
[159156.714892] nilfs_btree_propagate: key = 10, level == 0
...
...
...
[160276.691089] nilfs_btree_propagate: key = 10, level == 0
[160276.691096] NILFS warning (device dm-0): nilfs_clean_segments: segment construction failed. (err=-2)
[160281.690959] nilfs_btree_propagate: key = 10, level == 0
[160281.690967] NILFS warning (device dm-0): nilfs_clean_segments: segment construction failed. (err=-2)
What kernel version do you use?
What garbage collection policy do you use?
Could you share superblock content (nilfs-tune -l)?
I can still access the thumbdrive and it's contents. In the mean time many processes remain at D state and I have to force restart.
So, could you describe clear way of the issue reproducing on my side?
Thanks,
Vyacheslav Dubeyko.
I'm using 3.14.4. I thought there was only 1 selection policy, so it's
set to timestamp.
nilfs-tune -l /dev/bitcoin/bitcoin
nilfs-tune 2.1.6
Filesystem volume name: test
Filesystem UUID: 9e1064e0-4ce8-4831-93c0-758b46118884
Filesystem magic number: 0x3434
Filesystem revision #: 2.0
Filesystem features: (none)
Filesystem state: invalid or mounted
Filesystem OS type: Linux
Block size: 1024
Filesystem created: Sun Jun 22 15:31:18 2014
Last mount time: Thu Jun 26 11:26:50 2014
Last write time: Thu Jun 26 11:27:23 2014
Mount count: 5
Maximum mount count: 50
Reserve blocks uid: 0 (user root)
Reserve blocks gid: 0 (group root)
First inode: 11
Inode size: 128
DAT entry size: 32
Checkpoint size: 192
Segment usage size: 16
Number of segments: 11375
Device size: 23857201152
First data block: 4
# of blocks per segment: 2048
Reserved segments %: 1
Last checkpoint #: 208680
Last block address: 13015040
Last sequence #: 525413
Free blocks count: 3723264
Commit interval: 0
# of blks to create seg: 0
CRC seed: 0x1b525ab2
CRC check sum: 0xcede51d1
CRC check data size: 0x00000118
I suspect this has to do with the segment size. So I've re-formatted a
device with the default segment size. Let's see if I can reproduce it now.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
