Hi,

i know we don't really have an ntfs maintainer, and that nobody should
use ntfs, but interoperability...

i have a 8Tb 'seagate backup plus hub' appearing as:

uhub8 at uhub1 port 5 configuration 1 interface 0 "Seagate Backup+ Hub" rev 
2.10/48.85 addr 2
umass0 at uhub8 port 1 configuration 1 interface 0 "Seagate Backup+ Hub BK" rev 
2.10/1.00 addr 3
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
sd2 at scsibus4 targ 1 lun 0: <Seagate, Backup+ Hub BK, D781> SCSI4 0/direct 
fixed

which just has a huge ntfs partition:

# /dev/rsd2c:
type: SCSI
disk: SCSI disk
label: Backup+ Hub BK  
duid: 0000000000000000
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 972801
total sectors: 15628053167
boundstart: 0
boundend: 15628053167
drivedata: 0 

16 partitions:
#                size           offset  fstype [fsize bsize   cpg]
  c:      15628053167                0  unused                    
  i:           262144               34 unknown                    # /mnt/sd2
  j:      15627788288           264192   MSDOS              

(with -pG)
total sectors: 15628053167 # total bytes: 7452.0G
  c:          7452.0G                0  unused                    
  i:             0.1G               34 unknown                    # /mnt/sd2
  j:          7451.9G           264192   MSDOS      

Trying to mount it (dev/sd2j, of course) immediately panics the kernel
(hand-written):

panic: out of space in kmem_map
panic
malloc
ntfs_calccfree
ntfs_mountfs
ntfs_mount
sys_mount
syscall

I suppose pointing at
https://github.com/openbsd/src/blob/master/sys/ntfs/ntfs_vfsops.c#L567

So, what can be done to 1) avoid the panic and 2) eventually find a way to
support those partitions sizes ?

Landry

Reply via email to