On Thu, 2010-06-03 at 19:59 -0700, Sandon Van Ness wrote: > Did you do a commit fixing this today or maybe its working from other > patches you made to mkfs?
Yes I did. I ran out of time before sending out an email and was just getting ready to reply to you when I saw this. If everything holds up for a few more days I'll create a 1.1.15 release. Thanks, Shaggy > I just tried compiling the newest source from > svn and I created a file-system using the block device that before > failed fsck and now is working: > > r...@sabayonx86-64: 07:56 PM :~# mkfs.jfs /dev/sdd > mkfs.jfs version 1.1.14, Jun 3 2010 > Warning! All data on device /dev/sdd will be lost! > > Continue? (Y/N) y > | > > Format completed successfully. > > 34359367680 kilobytes total disk space. > r...@sabayonx86-64: 07:56 PM :~# fsck.jfs -v -f /dev/sdd > fsck.jfs version 1.1.14, Jun 3 2010 > processing started: 6/3/2010 19.57.2 > The current device is: /dev/sdd > Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 > Primary superblock is valid. > The type of file system for the device is JFS. > Block size in bytes: 4096 > Filesystem size in blocks: 8589841920 > **Phase 0 - Replay Journal Log > LOGREDO: Log already redone! > logredo returned rc = 0 > **Phase 1 - Check Blocks, Files/Directories, and Directory Entries > **Phase 2 - Count links > **Phase 3 - Duplicate Block Rescan and Directory Connectedness > **Phase 4 - Report Problems > **Phase 5 - Check Connectivity > **Phase 6 - Perform Approved Corrections > **Phase 7 - Rebuild File/Directory Allocation Maps > **Phase 8 - Rebuild Disk Allocation Maps > Filesystem Summary: > Blocks in use for inodes: 8 > Inode count: 64 > File count: 0 > Directory count: 1 > Block count: 8589841920 > Free block count: 8588497375 > 34359367680 kilobytes total disk space. > 0 kilobytes in 1 directories. > 0 kilobytes in 0 user files. > 0 kilobytes in extended attributes > 0 kilobytes in access control lists > 5378180 kilobytes reserved for system use. > 34353989500 kilobytes are available for use. > Filesystem is clean. > All observed inconsistencies have been repaired. > Filesystem has been marked clean. > **** Filesystem was modified. **** > processing terminated: 6/3/2010 19:57:33 with return code: 0 exit code: 0. > > > I also tested with a 36TB sparse file which appeared to be working as > well (not shoing the type of behavior it was before): > > r...@sabayonx86-64: 07:53 PM :/# dd bs=1M count=0 seek=36M of=./sparse.bin > 0+0 records in > 0+0 records out > 0 bytes (0 B) copied, 8.168e-06 s, 0.0 kB/s > r...@sabayonx86-64: 07:53 PM :/# > r...@sabayonx86-64: 07:54 PM :/# mkfs.jfs -s 128 -L data ./sparse.bin > mkfs.jfs version 1.1.14, Jun 3 2010 > Warning! All data on device ./sparse.bin will be lost! > > Continue? (Y/N) y > | > > Format completed successfully. > > 38654705664 kilobytes total disk space. > r...@sabayonx86-64: 07:54 PM :/# ls -lsah sparse.bin > 4.7G -rw-r--r-- 1 root root 36T 2010-06-03 19:54 sparse.bin > r...@sabayonx86-64: 07:54 PM :/# fsck.jfs sparse.bin > fsck.jfs version 1.1.14, Jun 3 2010 > processing started: 6/3/2010 19.54.55 > Using default parameter: -p > The current device is: sparse.bin > Block size in bytes: 4096 > Filesystem size in blocks: 9663676416 > **Phase 0 - Replay Journal Log > Filesystem is clean. > r...@sabayonx86-64: 07:54 PM :/# fsck.jfs -v -f sparse.bin > fsck.jfs version 1.1.14, Jun 3 2010 > processing started: 6/3/2010 19.54.59 > The current device is: sparse.bin > Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 > Primary superblock is valid. > The type of file system for the device is JFS. > Block size in bytes: 4096 > Filesystem size in blocks: 9663676416 > **Phase 0 - Replay Journal Log > LOGREDO: Log already redone! > logredo returned rc = 0 > **Phase 1 - Check Blocks, Files/Directories, and Directory Entries > **Phase 2 - Count links > **Phase 3 - Duplicate Block Rescan and Directory Connectedness > **Phase 4 - Report Problems > **Phase 5 - Check Connectivity > **Phase 6 - Perform Approved Corrections > **Phase 7 - Rebuild File/Directory Allocation Maps > **Phase 8 - Rebuild Disk Allocation Maps > Filesystem Summary: > Blocks in use for inodes: 8 > Inode count: 64 > File count: 0 > Directory count: 1 > Block count: 9663676416 > Free block count: 9662167893 > 38654705664 kilobytes total disk space. > 0 kilobytes in 1 directories. > 0 kilobytes in 0 user files. > 0 kilobytes in extended attributes > 0 kilobytes in access control lists > 6034092 kilobytes reserved for system use. > 38648671572 kilobytes are available for use. > Filesystem is clean. > All observed inconsistencies have been repaired. > Filesystem has been marked clean. > **** Filesystem was modified. **** > processing terminated: 6/3/2010 19:55:33 with return code: 0 exit code: 0. > r...@sabayonx86-64: 07:55 PM :/# > > On 06/03/2010 05:12 AM, Dave Kleikamp wrote: > > I apologize for not getting back to this sooner. I've been busy with > > other work and neglecting jfs. I'll take a look at this later today and > > hopefully figure out what needs to be fixed. > > > > Sorry I've been so unresponsive. > > > > Shaggy > > > > On Thu, 2010-06-03 at 03:14 -0700, Sandon Van Ness wrote: > > > >> The mkfs.jfs would properly create things right near the 32 TiB border > >> but I then found out that fsck would crap out even though mkfs.jfs would > >> properly create the file-system (atleast write more than just the log > >> and actually write data to the device): > >> > >> > >> sabayonx86-64 / # mkfs.jfs -s 128 -L data /dev/sdd1 > >> mkfs.jfs version 1.1.14, 06-Apr-2009 > >> Warning! All data on device /dev/sdd1 will be lost! > >> > >> Continue? (Y/N) y > >> | > >> > >> Format completed successfully. > >> > >> 34328444232 kilobytes total disk space. > >> sabayonx86-64 / # fsck.jfs -v -f /dev/sdd1 > >> fsck.jfs version 1.1.14, 06-Apr-2009 > >> processing started: 6/3/2010 3.4.24 > >> The current device is: /dev/sdd1 > >> Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 > >> Primary superblock is valid. > >> The type of file system for the device is JFS. > >> Block size in bytes: 4096 > >> Filesystem size in blocks: 8582111058 > >> **Phase 0 - Replay Journal Log > >> LOGREDO: Log already redone! > >> logredo returned rc = 0 > >> **Phase 1 - Check Blocks, Files/Directories, and Directory Entries > >> **Phase 2 - Count links > >> **Phase 3 - Duplicate Block Rescan and Directory Connectedness > >> **Phase 4 - Report Problems > >> **Phase 5 - Check Connectivity > >> **Phase 6 - Perform Approved Corrections > >> **Phase 7 - Rebuild File/Directory Allocation Maps > >> **Phase 8 - Rebuild Disk Allocation Maps > >> ujfs_rw_diskblocks: disk_count is 0 > >> Unrecoverable error writing M to /dev/sdd1. CANNOT CONTINUE. > >> Fatal error (-10091,87) accessing the filesystem (2,221184,0,0). > >> **** Filesystem was modified. **** > >> processing terminated: 6/3/2010 3:04:25 with return code: -10091 exit > >> code: 4. > >> > >> > >> I ended up having to make the file-system 99.9% of 32 TiB which meant I > >> cut off 32 GiB off the file-system and then the fsck would correctly > >> continue: > >> > >> sabayonx86-64 / # mkfs.jfs -s 128 -L data /dev/sdd1 > >> mkfs.jfs version 1.1.14, 06-Apr-2009 > >> Warning! All data on device /dev/sdd1 will be lost! > >> > >> Continue? (Y/N) y > >> | > >> > >> Format completed successfully. > >> > >> 34325008295 kilobytes total disk space. > >> sabayonx86-64 / # fsck.jfs -v -f /dev/sdd1 > >> fsck.jfs version 1.1.14, 06-Apr-2009 > >> processing started: 6/3/2010 3.5.20 > >> The current device is: /dev/sdd1 > >> Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 > >> Primary superblock is valid. > >> The type of file system for the device is JFS. > >> Block size in bytes: 4096 > >> Filesystem size in blocks: 8581252073 > >> **Phase 0 - Replay Journal Log > >> LOGREDO: Log already redone! > >> logredo returned rc = 0 > >> **Phase 1 - Check Blocks, Files/Directories, and Directory Entries > >> **Phase 2 - Count links > >> **Phase 3 - Duplicate Block Rescan and Directory Connectedness > >> **Phase 4 - Report Problems > >> **Phase 5 - Check Connectivity > >> **Phase 6 - Perform Approved Corrections > >> **Phase 7 - Rebuild File/Directory Allocation Maps > >> **Phase 8 - Rebuild Disk Allocation Maps > >> Filesystem Summary: > >> Blocks in use for inodes: 8 > >> Inode count: 64 > >> File count: 0 > >> Directory count: 1 > >> Block count: 8581252073 > >> Free block count: 8579908839 > >> 34325008292 kilobytes total disk space. > >> 0 kilobytes in 1 directories. > >> 0 kilobytes in 0 user files. > >> 0 kilobytes in extended attributes > >> 0 kilobytes in access control lists > >> 5372936 kilobytes reserved for system use. > >> 34319635356 kilobytes are available for use. > >> Filesystem is clean. > >> All observed inconsistencies have been repaired. > >> Filesystem has been marked clean. > >> **** Filesystem was modified. **** > >> processing terminated: 6/3/2010 3:05:57 with return code: 0 exit code: > >> 0. > >> > >> So > >> 34325008295 kilobytes > >> > >> is the largest I could make the file-system and fsck without any errors. > >> I guess I will try to completely fill the file-system up to make sure > >> that it doesn't give me any new errors when it is near full but can I > >> assume it will probably work ok as the mkfs.jfs and fsck is running ok? > >> > >> Sandon Van Ness wrote: > >> > >>> I am planning on having a file-system that is over 32TB in the very near > >>> future and I heard from someone that JFS can't handle file-systems over > >>> 32 TB correctly (can't expand, fsck, or anything). I believe this is > >>> indeed true as I just tried formatting a file-system that was 31 TB via > >>> a sparse file and it took a bit of time to format and ended up with a > >>> file with about 5 GB of usage: > >>> > >>> r...@sabayonx86-64: 05:31 PM :/data# mkfs.jfs -s 1024 /data/sparse_jfs > >>> mkfs.jfs version 1.1.14, 06-Apr-2009 > >>> Warning! All data on device /data/sparse_jfs will be lost! > >>> > >>> Continue? (Y/N) y > >>> - > >>> > >>> Format completed successfully. > >>> > >>> 33285996544 kilobytes total disk space. > >>> > >>> > >>> r...@sabayonx86-64: 05:32 PM :~# ls -lsah /data/sparse_jfs > >>> 4.9G -rw-r--r-- 1 root root 31T 2010-04-20 17:32 /data/sparse_jfs > >>> > >>> However, when I made this 2 TB bigger (to 33 TB) the format went much > >>> quicker and the end result was a sparse file with only 1.1 GB used: > >>> > >>> r...@sabayonx86-64: 05:32 PM :/data# mkfs.jfs -s 1024 /data/sparse_jfs > >>> mkfs.jfs version 1.1.14, 06-Apr-2009 > >>> Warning! All data on device /data/sparse_jfs will be lost! > >>> > >>> Continue? (Y/N) y > >>> - > >>> > >>> Format completed successfully. > >>> > >>> 35433480192 kilobytes total disk space. > >>> r...@sabayonx86-64: 05:32 PM :/data# ls -lsah /data/sparse_jfs > >>> 1.1G -rw-r--r-- 1 root root 33T 2010-04-20 17:33 /data/sparse_jfs > >>> > >>> > >>> So obviously there is some bug here as if anything it should be writing > >>> more data. Also the used space amount after mounting it is also about > >>> the size I would expect from the sparse file minus the log size: > >>> > >>> Again used size just about doubles with a 64TB file-system but the > >>> sparse file is still much smaller than with a 31 TB file-system: > >>> > >>> r...@sabayonx86-64: 05:37 PM :/data# dd if=/dev/zero of=sparse_jfs bs=1M > >>> count=0 seek=64M > >>> 0+0 records in > >>> 0+0 records out > >>> 0 bytes (0 B) copied, 1.1877e-05 s, 0.0 kB/s > >>> r...@sabayonx86-64: 05:37 PM :/data# mkfs.jfs -s 1024 /data/sparse_jfs > >>> mkfs.jfs version 1.1.14, 06-Apr-2009 > >>> Warning! All data on device /data/sparse_jfs will be lost! > >>> > >>> Continue? (Y/N) y > >>> - > >>> > >>> Format completed successfully. > >>> > >>> 68719476736 kilobytes total disk space. > >>> r...@sabayonx86-64: 05:38 PM :/data# mount -o loop -t jfs > >>> /data/sparse_jfs /mnt/sparse/ > >>> r...@sabayonx86-64: 05:38 PM :/data# df -h /mnt/sparse/ > >>> Filesystem Size Used Avail Use% Mounted on > >>> /data/sparse_jfs 65T 8.1G 64T 1% /mnt/sparse > >>> > >>> However trying to copy anything to it immediately errors out: > >>> > >>> r...@sabayonx86-64: 05:39 PM :/mnt/sparse# cp -avf /opt ./ > >>> cp: cannot create directory `./opt': Input/output error > >>> r...@sabayonx86-64: 05:39 PM :/mnt/sparse# > >>> > >>> ERROR: (device loop1): dbAllocNext: Corrupt dmap page > >>> ERROR: (device loop1): remounting filesystem as read-only > >>> > >>> ialloc: diAlloc returned -5! > >>> > >>> > >>> With the 32 TB sparse file it works as expected and the cp runs without > >>> any problem: > >>> > >>> r...@sabayonx86-64: 05:40 PM :/data# dd if=/dev/zero of=sparse_jfs bs=1M > >>> count=0 seek=31M > >>> 0+0 records in > >>> 0+0 records out > >>> 0 bytes (0 B) copied, 1.2172e-05 s, 0.0 kB/s > >>> r...@sabayonx86-64: 05:40 PM :/data# mkfs.jfs -s 1024 /data/sparse_jfs > >>> mkfs.jfs version 1.1.14, 06-Apr-2009 > >>> Warning! All data on device /data/sparse_jfs will be lost! > >>> > >>> Continue? (Y/N) y > >>> - > >>> > >>> Format completed successfully. > >>> > >>> 33285996544 kilobytes total disk space. > >>> r...@sabayonx86-64: 05:41 PM :/data# ls -lsah /data/sparse_jfs > >>> 4.9G -rw-r--r-- 1 root root 31T 2010-04-20 17:41 /data/sparse_jfs > >>> > >>> r...@sabayonx86-64: 05:42 PM :/mnt/sparse# df -h /mnt/sparse/ > >>> Filesystem Size Used Avail Use% Mounted on > >>> /data/sparse_jfs 31T 3.9G 31T 1% /mnt/sparse > >>> r...@sabayonx86-64: 05:42 PM :/mnt/sparse# cp -avf /opt/ ./ | wc -l > >>> 17426 > >>> r...@sabayonx86-64: 05:43 PM :/mnt/sparse# df -h /mnt/sparse/ > >>> Filesystem Size Used Avail Use% Mounted on > >>> /data/sparse_jfs 31T 5.5G 31T 1% /mnt/sparse > >>> r...@sabayonx86-64: 05:43 PM :/mnt/sparse# ls -lsah /data/sparse_jfs > >>> 6.0G -rw-r--r-- 1 root root 31T 2010-04-20 17:41 /data/sparse_jfs > >>> r...@sabayonx86-64: 05:43 PM :/mnt/sparse# > >>> > >>> Are there any plans to fix this? Ive got a feeling that its something > >>> simple as only the log seems to be written when doing the mkfs. > >>> > >>> > >>> ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Jfs-discussion mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/jfs-discussion > >>> > >>> > >>> > >> > >> ------------------------------------------------------------------------------ > >> ThinkGeek and WIRED's GeekDad team up for the Ultimate > >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > >> lucky parental unit. See the prize list and enter to win: > >> http://p.sf.net/sfu/thinkgeek-promo > >> _______________________________________________ > >> Jfs-discussion mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/jfs-discussion > >> > > > -- Dave Kleikamp IBM Linux Technology Center ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
