Join Log in
Score:0
Zorglub29 avatar Ubuntu

See actual raw binary content of the full disk block in which a file is written

ma flag
Zorglub29

If I have a file on disk (creating a healthy one for the sake of the discussion, but I may have one from before, possibly damaged, in some debugging activities):

/tmp/tmp.gEJmJSc2zQ> echo "hello" > hello.txt

I can see that this file, even if it is small, actually uses a full 4KiB block, as expected (this is the block size on my filesystem, default Ubuntu 20.04):

/tmp/tmp.gEJmJSc2zQ> ls -lsh hello.txt 
4,0K -rw-rw-r-- 1 jrmet jrmet 6 juni   6 14:27 hello.txt

I know how to get more information about the specific block used by the file:

/tmp/tmp.gEJmJSc2zQ> filefrag -b4096 -v hello.txt 
Filesystem type is: ef53
File size of hello.txt is 6 (1 block of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       0:   14582783..  14582783:      1:             last,eof
hello.txt: 1 extent found

My question is: how can I inspect the full raw binary data of the full 4KiB block containing this file, from start to end (i.e. not just the raw binary data of the file, I know how to do this with xxd already :) )? Is there a specific command that can show me this, and / or a smart combination of dd and xxd? I would be fine with a solution that either opens the full raw binary data of the 4KiB block in an editor such as xxd, and / or a way to dump these binary data to a file on disk (that I then know how to examine with any tool a la xxd).

57
1 + 8
Zorglub29 avatar
ma flag
Zorglub29
comment to myself: may need some info about what physical device the block is located into, may need to use some df and lvs commands / info? see: https://unix.stackexchange.com/questions/11311/how-do-i-find-on-which-physical-device-a-folder-is-located .
0
Reply
Zorglub29 avatar
ma flag
Zorglub29
comment to myself: see also explanations at https://unix.stackexchange.com/questions/463312/getting-block-size-via-df-vs-dumpe2fs .
0
Reply
waltinator avatar
it flag
waltinator
In between you and the raw disk block is a "filesystem". It uses the file *metadata* to tell you how much data is stored in the file. The 4KB allocation chunk is done for efficiency. The data in the "rest" of the block is not visible, because the metadata says it is beyond the EOF.
0
Reply
Zorglub29 avatar
ma flag
Zorglub29
I am well aware about this @waltinator , this is why I wonder / ask how to access the full 4KiB raw data block, not just the data until the EOF byte as done with usual file reading :) . I suspect there are actually ways to access these data - even if this requires using low level tools- for debugging etc purposes for example. I suppose this may request some dd magics or other raw device reading command, which is the point of this question.
0
Reply
hr flag
steeldriver
If the filesystem is ext2/3/4 you could use the `debugfs` utility's `block_dump` command - however it elides sequences of null bytes (in the same way as `xxd`), so unless it really is corrupted in some way you likely won't see much beyond the initial non-null content.
1
Reply
Zorglub29 avatar
ma flag
Zorglub29
@steeldriver my case (default install on ubuntu 20.04) is with ext4, so a solution that covers it would be great :) . If you can show an example of using debugfs to do it (printout of terminal), that would be very useful / a nice answer (I am not familiar with debugfs so showing a step by step explanation would be helpful if you are ok providing it :) ).
0
Reply
hr flag
steeldriver
@Zorglub29 please see below
1
Reply
Zorglub29 avatar
ma flag
Zorglub29
Amazing, many thanks, this is exactly what I was looking for :) .
0
Reply
Score:1
avatar Ubuntu
hr flag
steeldriver

The debugfs ext2/ext3/ext4 file system debugger has a block_dump command that outputs bytes similarly to the default output format of the xxd command. Unlike xxd there doesn't appear to be a way to turn off the elision of null bytes so you will see a single * for any number of contiguous 32-byte sequences - you will only see the "full" block if it actually is "full".

The command's syntax provides for either an absolute block offset (obtained from the debugfs blocks command for example), or an offset relative to a "filespec" consisting of either an inode number in angle brackets or an absolute path.

So for example, given

$ ls -lis hello.txt
691662 4 -rw-rw-r-- 1 steeldriver steeldriver 6 Jun  7 08:39 hello.txt

where the filesystem is confirmed as

$ findmnt -T hello.txt
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda1 ext4   rw,relatime

then (interactively)

$ sudo debugfs /dev/sda1
[sudo] password for steeldriver: 
debugfs 1.46.5 (30-Dec-2021)
debugfs:  
debugfs:  block_dump -f /home/steeldriver/dir/hello.txt 0
0000  6865 6c6c 6f0a 0000 0000 0000 0000 0000  hello...........
0020  0000 0000 0000 0000 0000 0000 0000 0000  ................
*

debugfs:

or

debugfs:  block_dump -f <691662> 0
0000  6865 6c6c 6f0a 0000 0000 0000 0000 0000  hello...........
0020  0000 0000 0000 0000 0000 0000 0000 0000  ................
*

debugfs:

or

debugfs:  blocks <691662>
5151850 
debugfs:  block_dump 5151850
0000  6865 6c6c 6f0a 0000 0000 0000 0000 0000  hello...........
0020  0000 0000 0000 0000 0000 0000 0000 0000  ................
*

debugfs:

If you need to do it non-interactively, the -f option allows commands to be read from file or from standard input ex.

printf 'block_dump -f <%d> 0\n' "$(stat -c %i hello.txt)" | sudo debugfs -f - /dev/sda1

or you can use the -R option to execute a single request

sudo debugfs -R 'block_dump -f /home/steeldriver/dir/hello.txt 0' /dev/sda1

The filesystem is opened in read-only mode by default.

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.