1

I tried lseek and dd if=/dev/urandom seek=7 bs=4096 count=2 of=fwh, they didn't work on my computer. The ls -lks result is: 44 -rw-rw-r-- 1 guangmu guangmu 36864 Aug 10 18:19 fwh.

I tried rm the file, reboot, and even cleaning the blocks used by fwt via debugfs. These didn't help.

My filesystem is ext4, OS is ubuntu 14.04. Here is the result of sudo tune2fs -l /dev/sda5:

tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   
Last mounted on:          /
Filesystem UUID:          e051336c-6a7a-4683-9c24-1230676170b1
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              34594816
Block count:              138359808
Reserved block count:     6917990
Free blocks:              109566416
Free inodes:              33280312
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      991
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Mon Jan 20 20:56:20 2014
Last mount time:          Mon Aug 11 11:08:31 2014
Last write time:          Mon Aug 11 11:08:30 2014
Mount count:              387
Maximum mount count:      -1
Last checked:             Mon Jan 20 20:56:20 2014
Check interval:           0 ()
Lifetime writes:          743 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       18877404
Default directory hash:   half_md4
Directory Hash Seed:      780cc1b8-1fa1-4751-9385-270b563b29cd
Journal backup:           inode blocks

Did I do something wrong?

Guangmu Zhu
  • 31
  • 5

2 Answers2

0

No, that is correct. You have seeked (or sought maybe?) 7 blocks of 4096 bytes in fwh and then written 2 blocks of 4096 bytes to it. So you would expect fwh to contain 9 blocks of 4096 bytes, which is 36,864 bytes - exactly as you have.

Or have I missed something? What were you expecting?

Mark Setchell
  • 191,897
  • 31
  • 273
  • 432
  • According to APUE Section 3.6, if I `lseek` out of the end of a file, a sparse file will be made, and the actual blocks it occupied should be fewer than the file size. However it didn't work on my computer. I `lseek` 7 blocks and wrote 2 blocks with block-size=4096, and the `ls -lks` is `44 -rw-rw-r-- 1 guangmu guangmu 36864 Aug 10 18:19 fwh`. For more detail, you can see ["how-to-create-a-file-with-file-holes"](http://stackoverflow.com/questions/5315428/how-to-create-a-file-with-file-holes), it also didn't work on my computer. – Guangmu Zhu Aug 11 '14 at 03:38
  • Ok. I am using OSX HFS+ filesystem which doesn't support sparse files, so mine is correct. What filesystem are you using and what is your blocksize? `df -g ` and/or `fstyp -v /dev/dsk/something` – Mark Setchell Aug 11 '14 at 07:46
  • And while you are getting the FS type and blocksize, can you remove your file, re-run your `dd` command and re-run your `ls -lks` command and post the results please? Preferably do all that by 'editing your original question` rather than inside `Comments`. Thank you. – Mark Setchell Aug 11 '14 at 07:59
  • I edited my question, and I tried according to your suggestions, but the result didn't change. Thanks.@MarkSetchell – Guangmu Zhu Aug 11 '14 at 09:37
  • That is odd. Your blocksize is 4096 and your `dd` command has caused 44 blocks to be allocated on disk, whereas you would expect it to be 2 blocks, or at the very most, 9. I would try some experiments with `seek` set to 0,8,64,256, 1024 and see how the number of allocated blocks changes, to see if there is a straight-line relationship or what is going on. – Mark Setchell Aug 11 '14 at 10:19
  • I found the reason, it's my carelessness. while `/dev/sda5`(/) is a ext4 filesystem, `/home` is encrypted with `ecryptfs`(maybe it's default on Ubuntu?). I retried in another path, a sparse file was created. Thanks for your help!@MarkSetchell – Guangmu Zhu Aug 11 '14 at 10:32
  • Aha! That makes sense - good! We don't like unsolved mysteries :-) – Mark Setchell Aug 11 '14 at 10:42
0

It's my carelessness.:(

/home is mounted as ecrpyptfs, which doesn't support sparse file.

Guangmu Zhu
  • 31
  • 5