On Mar 17, 2014, at 10:13 AM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On Mon, 2014-03-17 at 10:25 -0400, Al Dunsmuir wrote: >> On Monday, March 17, 2014, 4:14:50 AM, Kamil Paral wrote: >>> I can't either, and even if I did, I don't think it would justify >>> the result number explosion. Storage is storage, arch is usually completely irrelevant. >> >>> When we're at it, why do we have both i686 and x86_64 at "Device >>> tests"? A single results column for x86 should be enough. Same reasoning. >> >> In the past, some filesystems have had issues handling 64-bit inodes >> in 32-bit architectures. User data is too important to make an >> assumption that these no longer will occur. > > Device tests are not filesystem tests, though. > > Could you provide some references to these issues? > > With either set of tests, though, I don't see that any 'user data' is > involved: in each case the only partitions we're creating or touching > are new ones with no user data involved. Even if one of the filesystems > we create might suffer from a bug further down the line, I don't think > any of these tests would catch it, would they? Maybe, but I think it's a really small surface area. I've got an i686 case where mkfs.blah permits the creation of a > 16TB volume, but fails to mount it in the case of ext4 and XFS. I'm told the mount failure is correct behavior (jury is still out on whether Btrfs permitting this is a bug or not). But probably the mkfs shouldn't be allowed. So if the installer permits 16+TB storage to be created, mkfs works, mount fails, installer blows up. Thing is, when I try to do this in the installer it sometimes permits me to create such large storage, and other times not and I haven't figured out a pattern so I gave up on anaconda 20, and need to redo this testing on 21. And then some of the storage devs seem to think any user creating such large storage on memory limited i686 hardware are crazy; yet I'm thinking, this is made easy by cheap i686 hardware and cheap 4+TB drives. So it's crazy, but it's a trap! So, maybe, I don't know. Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
