Reserved space problem after changing to 2TB drive

As I understand it, you can't just run resize2fs on ext3 as it doesn't take account of the journalling. You have first to convert to ext2, resize and then convert to ext3 again.
What is your reference for this assertion? I have just tried it on the Humax and online resizing works fine, and you don't have to do anything with the journalling:
Code:
humax ~ # df -h /mnt/hd3
Filesystem                Size      Used Available Use% Mounted on
/dev/sda3                 6.7G    271.5M      6.4G   4% /mnt/hd3

humax ~ # /mod/sbin/resize2fs /dev/sda3
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/sda3 is mounted on /mnt/hd3; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/sda3 to 2622611 (4k) blocks.
The filesystem on /dev/sda3 is now 2622611 (4k) blocks long.

humax ~ # df -h /mnt/hd3
Filesystem                Size      Used Available Use% Mounted on
/dev/sda3                 9.8G    271.5M      9.6G   3% /mnt/hd3
Livingroomhumax# /mod/sbin/resizefs /dev/sda2
/mod/sbin/resize2fs
it does appear that running resize2fs /dev/sda2 (NB resize2fs) in Maintenance Mode should result in the desired increase in video storage space.
You don't need to do it in maintenance mode. It works perfectly OK while the filesystem is mounted and the Humax software is running.

All the OP needs to do (now we've seen the data about the partition layout) should be just:
Code:
humax# opkg install e2fsprogs
humax# /mod/sbin/resize2fs /dev/sda2
humax# opkg remove e2fsprogs
humax# df -h /mnt/hd2
@/df Re your ???. There is a link under the word HERE which is blue to indicate a link. It's to the Foxsat custom thread on AVF.
What's any of this got to do with the Foxsat? Nothing. That's why /df said "???". 'tis you who is confused...
 
I replied to a different thread in this one.
What you mean is you confused this thread with the one running in the Foxsat CF section. That's what happens if you navigate the forum using the new posts listing instead of through the classification hierarchy.
 
Yeah, yeah, yeah. :p
No. That's what happens when you are stupid enough to have two tabs open on different threads without noticing it and you go off to find an external reference that could have easily been given in the first place. :frantic:
 
What is your reference for this assertion? I have just tried it on the Humax and online resizing works fine, and you don't have to do anything with the journalling:
...
Sounds like that would have been a limitation of an ext2fs (pre-ext3fs) version of resize2fs. Fortunately the CF repo version of e2fsprogs is quite up-to-date (in fact the same version as the Ubuntu 16.04-based laptop from which this post is coming).
...
You don't need to do [resize2fs] in maintenance mode. It works perfectly OK while the filesystem is mounted and the Humax software is running.
...
That's impressive. I still have a gut feeling that this sort of operation is best done offline, to reduce the possible failure modes.
 
I still have a gut feeling that this sort of operation is best done offline, to reduce the possible failure modes.
I think that's overly cautious. I've done it lots of times on various systems (admittedly with ext4, and usually on an LVM volume where you can both expand the volume and resize the FS in one convenient command) and it's been perfectly OK every time.
 
What is your reference for this assertion? I have just tried it on the Humax and online resizing works fine, and you don't have to do anything with the journalling:
I found several refs, including this from 2011, but also a suggestion that you can 'get away with it' if the original journal file is large enough.
I am an overly cautious person when it comes to this sort of operation.
 
I found several refs, including this from 2011, but also a suggestion that you can 'get away with it' if the original journal file is large enough.
...
In the linked article, the version of e2fsprogs is from 2006, when online resizing was introduced. The release notes don't suggest any general problem with ext3 resizing, though there was one with external journals.

The CF repo version is now 2 years behind the current version which does seem to have significant fixes, though obviously not significant enough for Ubuntu LTS.
I am an overly cautious person when it comes to this sort of operation.
+1
 
In the end I re-cloned from the failing 1tb to the new 2tb drive again using Ease US Partition Master 13.5 and also resized the partitioned with it. Thanks to member /df above I used the commands he kindly provided in maintenace mode to perform an online resize (or I think that is what it said).
I checked all was well and the size was OK after this and it was but to be sure I went back into maintenance mode and performed a disk check. This seem to find a lot wrong but corrected it all and I am now using the unit under my TV again. All data and mods have been retained and I now have 2TB of space. Thank you all
 
Was that easier than:
  1. Install 2TB drive in HDR-FOX and use menus to format natively;
  2. Connect 1TB drive to HDR-FOX by USB;
  3. Open a Telnet session and copy the content of the entire My Video partition from the 1TB drive to the equivalent partition on the 2TB drive.
?
 
Loads easier as I did not have to setup detect adds, auto unprotect, static ip, DNLA name, fan package, redring, samba, undelete with settings and the one I love but hate setting up is network shares automount. I use network shares automount to my Qnap nas all the time and this is how I saved my programs but take me forever for some reason to get it to work.
 
You have missed my point: the process outlined in post 30 would have transferred all your settings as well.

I don't regard that as good as setting everything up "clean", but it would have done the job - without having to fudge the disk structure.
 
Back
Top