Use the command ncdu. It is a console program to display disc usage. It has a ncurses GUI.
I usually run ncdu -x <some folder>, the x switch is there to not cross filesystem boundaries.
apt-get install ncdu
ncdu man page
Alas no, it is not possible to connect a SATA device to the SD slot.
Unlike earlier flash memory standards like Compact Flash, which essentially used a Parallel ATA hard drive interface (scaled down in size) to attach flash memory, SD cards use a 1 or 4 bit serial interface and (more importantly) a different command protocol.
CF cards spoke the ATA command ...
After lots of reading and frustration. First of all, make sure the normal user has read and write acces to the USB drive. The correct 'non-root' fix for having write acces to the USB drive is:
Step 1: Stop transmission daemon
sudo service transmission-daemon stop
Step 2: Add pi to debian-transmission group
sudo usermod -a -G debian-transmission pi
As explained in this question there are two methods of expanding the image. Below are two examples to expand the file by 1 kilobyte.
DD creates a non-sparse file
dd if=/dev/zero bs=1k count=1 >> myimage.img
Truncate creates a sparse file
truncate -s +1024 myimage
You probably want to use truncate. A sparse file only writes the metadata of the ...
An incredibly easy way of resizing the image is to use one of the qemu tools called qemu-img. This of course depends on the fact that you have qemu installed (which I know you already do Alex).
The command looks like this:
qemu-img resize filename [+|-]size[K|M|G|T]
Where filename is the image file, and size is the size you want to enlarge (or shrink) the ...
I'm no linux expert, but you could try this, might work.
Most of this is info came from
sudo service transmission-daemon stop
sudo nano /etc/init.d/transmission-daemon
# hit enter to overwrite
sudo service transmission-daemon start
I know running as root is a big linux ...
You can boot from the SD card then just use an attached SSD, but you can not get around using the SD card for booting.
Once booted you can make the SD card read only and make sure all the software etc is running of the SSD
As others have mentioned, df -h will give you overview. Also useful:
du -csh (show total disk space used in current tree)
du -csh /path (show total space used in specified tree)
du -csh (show space used in subdirectories)
You can also install the durep package which will give you a more granular breakdown of disk usage.
The Pi 2 should be able to run that HDD directly. However, by default the power to USB is limited to 600 mA, which is not enough (I've had the same issue with an external drive).
To make 1.2 A available -- which is fine if your power supply is up to it -- add the following to /boot/config.txt:
And reboot. Your HDD should now light up ...
This will not really happen on the Pi unless one puts loads of stuff on there.
SD cards come in five maximum speed classes:
Class 1: maximum speed of minimum 1 MB/s
Class 2: maximum speed of minimum 2 MB/s
Class 4: maximum speed of minimum 4 MB/s
Class 8: maximum speed of minimum 8 MB/s
Class 10: maximum speed of minimum 10 MB/s
Above 10 MB/s there are ...
du -s * | sort -nr | head
-s prevents a lot of unnecessary output, -nr sorts numerically in reverse order and head cuts only the interesting part, you may omit it if you prefer all the results.
Also, if you need just an overview of your file system you may use
Filesystem 1K-blocks Used Available Use% Mounted on
Linux kernel is caching disk operations. That means data is written not in real time, but when it is "time to do it".
There could be two reasons of behaviour you described:
1. Your SD card (or disk) is not fast enough to receive all the data you are producing.
2. Once in 30-40 seconds kernel is 'flushing' it's disk buffers, which unluckily freezes all disk ...
I think it's unlikely that a Pi would work well, if at all, with FreeNAS.
Note the recommendation on their download page:
The new recommended boot device size is 8GB. FreeNAS 11 requires 8GB of RAM to run properly.
The Raspberry Pi 3 has 1GB of RAM. So that requirement seems to not be met, and it's not looking great so far for FreeNAS.
obarthelemy of ...
I believe your problem is your USB stick is formatted as NFTS or FAT, filesystems that do not support the per-user/group permissions. The solution is to reformat as ext4. If you do that, you will also have much less lag if you are using your Pi as a media center. The drivers for the Pi are much faster when you use ext4.
Since you are using Linux as the remote system, you could use baobab to monitor the file system:
If you select Analyzer > Scan remote folder you should be able to remotely build a graphical tree map of the Raspberry Pi's file system, I have tested this using the SSH option and it does seem to work, but also seems a bit slow to generate the tree (I assume it ...
None of the answers here worked for me, so I am writing a new one referencing https://pimylifeup.com/raspberry-pi-torrentbox/ which worked great for me and allowed me to run transmission as pi user to access my USB drive. This is not directly answering the OP but this question is very popular (first Google result) for this sort of problem so I put it here.
I'm using a SanDisk Extreme Class 10 with UHS-U3 on my RPi3, I have the microSD driver overclocked and I hit 33.80MB/s while reading/writing.
Speed don't decrease with capacity, just ensure to use a good brand like SanDisk (Samsung had a hight corrupt % chances), If you need some speed, try to overclock your microSD card driver.
More info here
Already answered here dd-on-entire-disk-but-do-not-want-empty-portion
Assuming you want to save /dev/sdXN to /tgtfs/image.raw and you are root:
mkdir /srcfs && mount /dev/sdXN /srcfs
Use zerofill or just:
dd if=/dev/zero of=/srcfs/tmpzero.txt
To fill unused blocks with zero (wait for it to fill the file system completely then
This seems to be a classical unix rights problem. Let's have a look on it. To avoid confusion I set user of /media/NAS to root and then check where is the problem:
pi@raspberry ~$ sudo chown root /media/NAS
pi@raspberry ~$ mkdir /media/NAS/folder-pi # works
pi@raspberry ~$ su -l pi2 # login as pi2
pi2@raspberry ~$ mkdir /media/NAS/...
Think this will have everything you need:
ITunes server, network shares and external drives, designed to run headless (so you SSH into it), now based on the updated rasbian (now much faster as it uses the hardware acceleration in the GPU to speed up general OS tasks), nice easy text menus to admin. I've ...
sudo hdparm -y /dev/sda
(assuming you only have one USB disc connected) can put your device into sleep. If you do this after unmounting the device, it should stay in this powersaving mode until you try to mount it again.
You may also try -Y option for sleep mode instead of stand by.
You can also try:
hdparm -k1 -K1 -S2 /dev/sda
which should spin your ...
Rather than moving the whole root partition, you could create a partition on the USB stick, and then pick a mount point for this where the space is required. For example, if you needed more space for downloaded apt packages, which live in /var/cache then you could mount the new partition on /var meaning that everything under this path would be stored in the ...
Another option could be to use an alternative to the Raspberry Pi with an SATA-interface, like the Cubieboard (see this list on Wikipedia).
On the other hand, SD cards are not as unreliable as you might think.
I suspect your issue is that you are mounting the vfat filesystem so that it is only accessible to the root user.
The vfat filesystem (being a very simple filesystem dating from the ancient days of DOS) has no concept of users and groups, but all files in UNIX systems must have an owner and group. To work around this, the Linux vfat driver defaults to ...
There are many ways you could set this up. You could use a whole host of software to mount the RPi's storage as an ftp or sftp drive, you could use OwnCloud, btsync, or a zillion other things that you could find by googling.