linux - DD: No Space Left On Device
2014-04
Petrusd987
I've been messing with an old Brother WP-2200 and I've hit a bit of a snag. I was hoping I would be able to make images out of the floppies I typed on it using dd under Linux. Unfortunately that hasn't worked. I've tried dd on about six different computers and they all have produced something similar to the following:
petrusd987@Peters-Gaming-Ubuntu:/tmp$ sudo dd if=/dev/zero of=/dev/sdd bs=1440k count=1
dd: writing to ‘/dev/sdd’: No space left on device
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000530324 s, 0.0 kB/s
This also produces the same result when done in reverse. I don't understand why this is happening because I know for a fact that the floppy I used in the device was working perfectly under dd before the WP-2200 formatted it. I do know that these machines use a proprietary file system not recognized by computers if that helps anyone. I didn't think that mattered though because DD works at the binary level. Any help in fixing this would be greatly appreciated.
Update:
I didn't really word this post very well so I'd like to try to make it a bit clearer. The disk was not write protected when I was working with it. Below is three of the commands I have tried and the output I am given:
I would like to point out that the floppy has changed to sdb when I rebooted because I have removed my external hard drive and flash drive.
**Copying: Writable**
sudo dd if=/dev/sdb of=/tmp/flp.img
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000530151 s, 0.0 kB/s
**Erasing: Read-only**
petrusd987@Peters-Gaming-Ubuntu:/tmp$ sudo dd if=/dev/zero of=/dev/sdb
[sudo] password for petrusd987:
dd: opening ‘/dev/sdb’: Read-only file system
**Erasing: Writable**
petrusd987@Peters-Gaming-Ubuntu:/tmp$ sudo dd if=/dev/zero of=/dev/sdb
dd: writing to ‘/dev/sdb’: No space left on device
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.00111174 s, 0.0 kB/s
This is my problem. I'm assuming that it is attempting to append to the floppy. This is not what I want. I want it to start at the beginning of the floppy and write the zeros. How do I do this?
terdon
The command you posted above will write 1440k of 0s into your floppy, it will not copy anything from it. Since the disk is full however, dd cannot write to the device and the command fails. Lucky you...
If you want to take an image of the data on the floppy do this:
dd if=/dev/sdd of=floppy.img
That will create a image file of your floppy called floppy.img. dd is a dangerous command, I recommend you read through man dd carefully before attempting to use it.
Another possible problem (assuming you run the dd correctly and not the way you have shown in your answer) is that the floppy is write protected. 31/2 inch floppies had a little switch that allowed you to toggle write protection (image from here):
Make sure that is in the correct position to allow writing. Normally, if a drive is mounted read only, you get a permission denied or similar error. I don't remember the error you got if attempting to write to a write protected floppy.
mpy
I do know that these machines use a proprietary file system not recognized by computers if that helps anyone. I didn't think that mattered though because DD works at the binary level.
You are right, dd doesn't bother about filesystems or what so ever. That is not the problem. I'm pretty sure now that the todays 3.5" floppy drives are the problem.
Remember, even if you use a 1.44MB (i.e. a HD) medium, that is saying nothing about the logical structure which is generated upon formatting. I mean, how much bytes per sector, how much sectors per track and how much tracks per medium are written.
Nowadays (ok, in the last decade) a 1.44MB floppy uses 512 bytes per sector, 18 sectors per track, 80 tracks per side and two sides, for a total of 1,474,560 bytes per disk [1][2]
If your Brother WP-2200 uses anything different from that (or the other formats used by PC drives; Microsoft's KB has a nice overview [3] or again a link to Wikipedia [4]), your dd command is doomed not to work, just because the floppy drive isn't able to read the bytes-secs-tracks geometry of the WP-2200 formatted disk. Usually in that case you hear a strange sound from your floppy drive, trying to find the tracks and sweeping back and forth a few times.
This forum thread supports my assumption.
Ashy
I decided to resize the partition on my storage drive (with gparted), all seemed to go well but now when I try to create directories or copy files to the drive I get a "No space left on device" error.
Also, even if I delete some files it does not allow me to replace them.
All of the files on the drive seem to be readable just fine and I can move the existing files into other directories with no problems.
There is space on the drive. Checking the size of all the files reports: 175,840 items, totalling 839.8 GB
It is an ext3 partition.
One wierd thing is that Ubuntu (64bit karmic) still picks the drive up as "957GB Filesystem" in the Places menu.
Note that the affected drive is not my main boot drive but simply a storage drive that I mount from the Places menu when needed.
Output of "df -h":
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 885G 842G 0 100% /media/acd61702-ff34-460f-8539-ac762d1dc466
Output of "df -i":
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb1 58433536 175818 58257718 1% /media/acd61702-ff34-460f-8539-ac762d1dc466
I have ran "fsck -f -v /dev/sdb1":
fsck from util-linux-ng 2.16
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
175818 inodes used (0.30%)
8348 non-contiguous files (4.7%)
142 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 76655/8046/56
222404925 blocks used (95.17%)
0 bad blocks
79 large files
161176 regular files
12907 directories
0 character device files
0 block device files
0 fifos
38 links
1726 symbolic links (1512 fast symbolic links)
0 sockets
--------
175847 files
Any help would be appreciated.
Thanks, e.
Edit: As requested "tune2fs -l /dev/sdb1":
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: acd61702-ff34-460f-8539-ac762d1dc466
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 58433536
Block count: 233703571
Reserved block count: 11685177
Free blocks: 11298646
Free inodes: 58257718
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 968
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 256
Filesystem created: Thu May 15 14:59:19 2008
Last mount time: Fri Nov 13 13:47:23 2009
Last write time: Fri Nov 13 14:40:32 2009
Mount count: 2
Maximum mount count: 35
Last checked: Thu Nov 12 15:14:03 2009
Check interval: 15552000 (6 months)
Next check after: Tue May 11 16:14:03 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 793715af-66d6-46da-82aa-97ab4549b0ad
Journal backup: inode blocks
gorilla
Firstly, you can't simply add up the sizes of all the files on the disk, and expect that to be the total amount used. Every time you store a file, there is some space wasted. It's like putting books on a shelf, if the books vary in size, then you're going to have a space between the top of the book and the bottom of the next shelf.
Secondly, if you have any files which are open but deleted, then the space that is used will still be used until the program with that file either closes it, or exits. That's often used for temporary files, the program doesn't have to worry about cleaning them up, all it needs to do is open a file, then delete it, before working with it. These files used space will show up in df, but you can't find a filename which corresponds to it. If you want to find them, then you'll have to look in /proc/*/fd
Thirdly, and this is your issue here, ext3 file systems have a percentage of reserved space which can only be written to by root. There are two reasons for this, many file systems become inefficient when the disk becomes close to becoming full, the system has to spend more and more time fitting files into the spaces that are left. Also reading and writing to the files is slow, as they end up being badly fragmented. Another reason for reserving space for root is that it allows root to compress files and hopefully recover some space for the users. If the disk was totally full, then that wouldn't be possible.
Therefore, there is nothing wrong, what you are seeing is normal behaviour for a full disk.
Ryan Thompson
It says that the filesystem is 100% used and has 0 available space. The filesystem is full. For various reasons, Avail + Used != Size.
Ashy
Ok, you were all right, it was full :D
Thanks to quack for the tune2fs comment I see where I went wrong:
Reserved block count: 11685177
Free blocks: 11298646
I have just moved about 60GB from the drive and it is now working as it should :)
Thank you all for your help.