On Sun, 02 Jun 2013 07:11:11 -0500 Dale <rdalek1...@gmail.com> wrote:
> Fast Turtle wrote: > > I've been going around with this little problem for a while. > > > > I have several 30GB files I'm trying to restore from an NTFS formatted > > external backup to an ext3 partition, yet every attempt has failed right > > after 16GB of copying without fail or error message. They silently failing > > and I'm stumped. > > > > One of the possible causes I've thought of was running out of innodes but > > don't know how to check that or any of the other options used to create the > > file system on - anyone want to help there? > > > > I've also decided to look at the mke2f.conf file in /etc and see some > > default options being passed that may be causing the problems > > > > [defaults] > > base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr > > default_mntopts = acl,user_xattr > > enable_periodic_fsck = 0 > > blocksize = 4096 > > inode_size = 256 > > inode_ratio = 16384 > > > > Normally I use either a 1024 for most everything due to the many small > > files though for the partition I'm attempting to restore the files to, I've > > used 2048 as a compromise due to the number of larger files (music/videos) > > and critical backups from /etc > > > > I've also tried it with a default 4096 size on a 32GB ext2 formatted flash > > drive but even then, it's failing at 16GB w/o any error message. > > > > > > > I can offer this: df -i shows inodes. > > root@fireball / # df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > rootfs 1525920 22728 1503192 2% / > /dev/sda6 1525920 22728 1503192 2% / > devtmpfs 2049540 593 2048947 1% /dev > tmpfs 2058249 654 2057595 1% /run > shm 2058249 2 2058247 1% /dev/shm > /dev/sda1 98392 794 97598 1% /boot > /dev/mapper/OS-usr 1638400 462712 1175688 29% /usr > /dev/mapper/OS-var 1703936 259049 1444887 16% /var > /dev/mapper/home-home 183148544 316215 182832329 1% /home > /dev/mapper/backup-backup 61046784 5818 61040966 1% /backup > tmpfs 2058249 122993 1935256 6% /var/tmp/portage > root@fireball / # > > > Hope that helps on that part at least. > > Dale > > :-) :-) > > -- > I am only responsible for what I said ... Not for what you understood or how > you interpreted my words! > > Thanks Dale - Interesting what info you can get All: Accidently discovered that tune2fs -l /dev/sda# lists all of the config info so I shouldn't have any problems Filesystem volume name: home Last mounted on: <not available> Filesystem UUID: d4102f68-defd-497b-84e4-f165fd171ed7 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 39075840 Block count: 156282705 Reserved block count: 7814135 Free blocks: 104269552 Free inodes: 38399824 First block: 0 Block size: 4096 Fragment size: 4096 Had KDE lockup the other day and it forced a clean install w/o it. Seems I inadvertently formatted /home using the standard 4k block size this time around. Would explain why the 30GB files copied over w/o issue this time I'll repost this: Thanks for the Wiki Entry Alan (keep forgetting to check it) as that certainly explains the issue and I'm going to put that into my System Log book (important notes section). When I started playing with Linux back in 2000, I never thought much about file size limits as ext2 could handle files larger then Win98 could. Now it's come full circle as you do have to be aware of the formatting because it can affect file size limits as I discovered.
