Re: 4k-sector NTFS can't be mounted
On Sun, Jul 21, 2013 at 11:45:47PM +0200, David Vasek wrote: > On Sun, 21 Jul 2013, Kenneth R Westerback wrote: > > >>A 4k-sector NTFS filesystem > >>can't be mounted as of 5.3/i386. > > > >At least one person is using a 4K-sector disk with NTFS partition(s) > >without problems. So I suspect something local to your setup is causing > >the problem by traversing new and exciting code paths. > > The filesystem was on external USB hard drive, as it came from the > manufacturer, which is HGST, formerly Hitachi GST, now part of WD. > The filesystem didn't work with OpenBSD 5.3/i386, but Windows XP > seemed happy with it. The filesystem was empty and from original 4 > TB it could be compressed with bzip2 to under 3 MB. I can send the > compressed image to you if you want to play with it and have extra > disk space. > > Regards, > David > No need. I've got my own 4K-byte sector, 4TB USB disks with NTFS partitions. And an absolute disinterest in NTFS. :-) Ken
Re: 4k-sector NTFS can't be mounted
On 07/21/13 23:14, Kenneth R Westerback wrote: On Sun, Jul 21, 2013 at 10:46:08PM +0200, David Vasek wrote: Hello, I guess this one is something expected. Nope, not expected. A 4k-sector NTFS filesystem can't be mounted as of 5.3/i386. At least one person is using a 4K-sector disk with NTFS partition(s) without problems. So I suspect something local to your setup is causing the problem by traversing new and exciting code paths. Could it simply be a Dynamic NTFS volume, which we don't support? /Alexander Ken OTOH, it works with Windows XP. Can't say if it is a bug since there is no public NTFS specifications. But Windows people are using such filesystems. Regards, David dmesg: -- umass2 at uhub0 port 5 configuration 1 interface 0 "HGST Touro Desk 3.0" rev 2.10/0.00 addr 4 umass2: using SCSI over Bulk-Only scsibus5 at umass2: 2 targets, initiator 0 sd5 at scsibus5 targ 1 lun 0: SCSI4 0/direct fixed serial.49711015110B1677 sd5: 3815446MB, 4096 bytes/sector, 976754431 sectors fdisk: -- Disk: sd5 geometry: 60800/255/63 [976754431 4096-byte Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 07 0 1 1 - 60799 254 63 [ 63: 976751937 ] NTFS 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused disklabel: -- # /dev/rsd5c: type: SCSI disk: SCSI disk label: HGST duid: flags: bytes/sector: 4096 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60800 total sectors: 976754431 boundstart: 0 boundend: 976754431 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c:9767544310 unused i:976751937 63NTFS
Re: 4k-sector NTFS can't be mounted
On Sun, Jul 21, 2013 at 10:46:08PM +0200, David Vasek wrote: > Hello, > > I guess this one is something expected. Nope, not expected. > A 4k-sector NTFS filesystem > can't be mounted as of 5.3/i386. At least one person is using a 4K-sector disk with NTFS partition(s) without problems. So I suspect something local to your setup is causing the problem by traversing new and exciting code paths. Ken >OTOH, it works with Windows XP. > Can't say if it is a bug since there is no public NTFS > specifications. But Windows people are using such filesystems. > > Regards, > David > > dmesg: > -- > umass2 at uhub0 port 5 configuration 1 interface 0 "HGST Touro Desk 3.0" rev > 2.10/0.00 addr 4 > umass2: using SCSI over Bulk-Only > scsibus5 at umass2: 2 targets, initiator 0 > sd5 at scsibus5 targ 1 lun 0: SCSI4 0/direct fixed > serial.49711015110B1677 > sd5: 3815446MB, 4096 bytes/sector, 976754431 sectors > > fdisk: > -- > Disk: sd5 geometry: 60800/255/63 [976754431 4096-byte Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start:size ] > --- > 0: 07 0 1 1 - 60799 254 63 [ 63: 976751937 ] NTFS > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > disklabel: > -- > # /dev/rsd5c: > type: SCSI > disk: SCSI disk > label: HGST duid: > flags: > bytes/sector: 4096 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 60800 > total sectors: 976754431 > boundstart: 0 > boundend: 976754431 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] > c:9767544310 unused > i:976751937 63NTFS
Re: 4k-sector NTFS can't be mounted
On Sun, 21 Jul 2013, Kenneth R Westerback wrote: A 4k-sector NTFS filesystem can't be mounted as of 5.3/i386. At least one person is using a 4K-sector disk with NTFS partition(s) without problems. So I suspect something local to your setup is causing the problem by traversing new and exciting code paths. The filesystem was on external USB hard drive, as it came from the manufacturer, which is HGST, formerly Hitachi GST, now part of WD. The filesystem didn't work with OpenBSD 5.3/i386, but Windows XP seemed happy with it. The filesystem was empty and from original 4 TB it could be compressed with bzip2 to under 3 MB. I can send the compressed image to you if you want to play with it and have extra disk space. Regards, David
4k-sector NTFS can't be mounted
Hello, I guess this one is something expected. A 4k-sector NTFS filesystem can't be mounted as of 5.3/i386. OTOH, it works with Windows XP. Can't say if it is a bug since there is no public NTFS specifications. But Windows people are using such filesystems. Regards, David dmesg: -- umass2 at uhub0 port 5 configuration 1 interface 0 "HGST Touro Desk 3.0" rev 2.10/0.00 addr 4 umass2: using SCSI over Bulk-Only scsibus5 at umass2: 2 targets, initiator 0 sd5 at scsibus5 targ 1 lun 0: SCSI4 0/direct fixed serial.49711015110B1677 sd5: 3815446MB, 4096 bytes/sector, 976754431 sectors fdisk: -- Disk: sd5 geometry: 60800/255/63 [976754431 4096-byte Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 07 0 1 1 - 60799 254 63 [ 63: 976751937 ] NTFS 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused disklabel: -- # /dev/rsd5c: type: SCSI disk: SCSI disk label: HGST duid: flags: bytes/sector: 4096 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60800 total sectors: 976754431 boundstart: 0 boundend: 976754431 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c:9767544310 unused i:976751937 63NTFS
Re: 4k-sector drives
Hello again.
disklabel(8) writes its label sector outside of A6 partition, possibly into
other partitions and overwrites data there. Looks like 512-byte sectors
are silently expected somewhere here, but I didn't check the code.
In the example below the label sector has been written to offset
1000 (4096-bytes sectors, byte 0x3e8200) and overwrote data in fdisk
partition 0 (see the hexdump output below). The offset in bytes from the
beginning of the disk is the same as would be if 512-byte sectors were
used instead of 4k-sectors. Filesystem /dev/sd4a starts where fdisk(8)
and disklabel(8) say, at sector 8000 (4096-bytes sectors), which is
visible from the hexdump.
Label sector is definitly not expected where it is written to.
From disklabel(5):
The label is located in sector number LABELSECTOR of the drive, usually
sector 0 where it may be found without any information about the disk
geometry. It is at an offset LABELOFFSET from the beginning of the
sector, to allow room for the initial bootstrap.
Also note wrong number of used sectors newfs(8) reported in this example:
"100.0MB in 204800 sectors of 4096 bytes".
The number would be correct if the sectors were 512-bytes in size.
I'm not usually using mixture of OS's on a system or even a drive, but
there are people who do and this can bite them. Also don't forget service
partitions and so on.
(fxp0 MAC number and sd4 serial were modified.)
OpenBSD/i386 BOOT 3.21
boot> bsd.rd
booting hd0a:kernel/i386/bsd.rd:
/-\|/-\|/6043500-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-+433856
[52+235056\|/-\|/-\|/-\|/+223307-\|/-\|/-\|/-]=0x69d650
entry point at 0x200120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.4 (RAMDISK_CD) #25: Wed Jul 17 10:11:20 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF
real mem = 526839808 (502MB)
avail mem = 510959616 (487MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/24/08, BIOS32 rev. 0 @ 0xfa080, SMBIOS
rev. 2.4 @ 0xf (34 entries)
bios0: vendor Phoenix Technologies, LTD version "MS7336 1.14" date 11/24/2008
bios0: Hewlett-Packard HP Compaq dx2300 Microtower
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC HPET MCFG APIC SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus -1 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 2 (HUB0)
bios0: ROM list: 0xc/0xb000! 0xcc000/0x1800
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82946GZ Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82946GZ PCIE" rev 0x02: apic 4 int 16
pci1 at ppb0 bus 1
vga1 at pci0 dev 2 function 0 "Intel 82946GZ Video" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel 82801GB HD Audio" rev 0x01 at pci0 dev 27 function 0 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 4 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 4 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 4 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 4 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 4 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
pci2 at ppb1 bus 2
fxp0 at pci2 dev 8 function 0 "Inte
Re: 4k-sector drives
On Sun, Jul 21, 2013 at 04:55:35PM +0200, David Vasek wrote: > Hello misc@, > > are disks with logical sector sizes other than 512-bytes supported? > I can get basic functionality with a 4k-sector drive, still there > are some flaws. Does it make sense to report these bugs now, or is > it too early? > > Regards, > David > Disks with logical sector sizes other than 512-bytes are supported. I am unaware of any outstanding issues with support for 4K sector devices. Ken
Re: 4k-sector drives
David Vasek wrote: > I met quite a few flaws when working with 4k-sector drives. I am not sure > if such drives are supported. If they are not supported yet They are supported and I wouldn't expect any "flaws". > Simply put: shall I send any reports concerning 4k-sectors on -cuurent? Yes. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: 4k-sector drives
On 2013 Jul 21 (Sun) at 18:44:11 +0200 (+0200), David Vasek wrote: :Detailed question once again: :Does it makes sense to report bugs YES. -- Patageometry, n.: The study of those mathematical properties that are invariant under brain transplants.
Re: 4k-sector drives
In general, what I've seen is that if something works, but has a bug, submit a bug report.
Re: 4k-sector drives
> Explanation: > I met quite a few flaws when working with 4k-sector drives. Since you won't describe the flaws at all, I think you are full of it.
Re: 4k-sector drives
On Sun, 21 Jul 2013, Theo de Raadt wrote: are disks with logical sector sizes other than 512-bytes supported? I can get basic functionality with a 4k-sector drive, still there are some flaws. Does it make sense to report these bugs now, or is it too early? Thanks for your very detailed question. Detailed answer follows: Detailed question once again: Does it makes sense to report bugs concerning disks with other sector sizes then 512 bytes now? Explanation: I met quite a few flaws when working with 4k-sector drives. I am not sure if such drives are supported. If they are not supported yet and that what works with these drives it works just by pure luck then it would be a waste of developers' time and bandwith to report such shortcomings. If the OS needs a complex work on non-512-bytes sector sizes a everybody knows it, then reporting those bugs (which in fact would not be bugs, becasue there is no "bug of unsupported feature") would not help anybody. Simply put: shall I send any reports concerning 4k-sectors on -cuurent? Thank you. Regards, David
Re: 4k-sector drives
> are disks with logical sector sizes other than 512-bytes supported? I can > get basic functionality with a 4k-sector drive, still there are some > flaws. Does it make sense to report these bugs now, or is it too early? Thanks for your very detailed question. Detailed answer follows:
4k-sector drives
Hello misc@, are disks with logical sector sizes other than 512-bytes supported? I can get basic functionality with a 4k-sector drive, still there are some flaws. Does it make sense to report these bugs now, or is it too early? Regards, David
Re: current/macppc on Mac Mini
> Ha! This seems to assume that the (fdisk) DOS partition > is the 'i' partition in the disklabel - it is not; > I created a [c]ustom disklabel. A bunch of architectures work this way. And it is a quite normal expectation that the 'i' partition match the 'spoofed label' semantics. But for now I think you are the one who made the assumption that your machine can be setup *differently* .. and that everything would work. If you want to come up with a fix for the install script that can auto-determine the partition, we'll be waiting.
Re: dhcp address in /etc/hosts
Kenneth R Westerback rogers.com> writes: > > I don't really get a vote as i'm not a developer, however cookies to anyone > > who fixes this the correct way. > > > > -- > > > > Sam Fourman Jr. > > > > Define 'correct way'. Personally, I have found running BIND and placing 127.0.0.1 to /etc/resolv.conf as most easier way to minimize /etc/hosts usage. I always thought of very minimalistic (read "secure") DNS server built-in into dhclient as a privsep process, so dhclient can dynamically push settings (based on a lease from DHCP server) via IMSG, so placing 127.0.0.1 to /etc/resolv.conf will "just work". I understand above approach maybe mixing things in non-unix way, but DHCP is designed so: it touches interface address, default gateway and resolver settings.
Re: OpenBSD ipsec performance on modern HW
On 2013 Jul 21 (Sun) at 14:16:32 +0300 (+0300), Evgeniy Sudyr wrote: :All, : :during my tests I seen that CPU on all cores and memory usage was very low. :Just interesting if there are any bottlenecks and how to fix them. Lots of bottlenecks. They can only be fixed in code, and others are working on them. :1) Does anybody care tcp stack tuning for high speed IPSEC ? the only thing you can do is select the modes that work best for your cpus. Others in this thread have done that already. :2) Can I run IPSEC (that's isakmpd ?) on other cores? No. : : :Pierre, :can you share your ipsec config to check same on my side. : -- Schwiggle, n.: The amusing rotation of one's bottom while sharpening a pencil. -- Rich Hall, "Sniglets"
Re: OpenBSD ipsec performance on modern HW
All, during my tests I seen that CPU on all cores and memory usage was very low. Just interesting if there are any bottlenecks and how to fix them. 1) Does anybody care tcp stack tuning for high speed IPSEC ? 2) Can I run IPSEC (that's isakmpd ?) on other cores? Pierre, can you share your ipsec config to check same on my side.
Re: dhcp address in /etc/hosts
On 07/21/13 09:24, Alexander Hall wrote: Since we by default allow dhclient to rewrite (and thus a dhcp server to dictate) our hostname, I'm wondering if a 'lookup hostname file bind' in resolv.conf could be useful... But I expect being flamed for it. :-) Thinking of it, what address would it use? egress:0? I dunno. /Alexander
Re: softdep issue in 5.3-current ?
The reported problems are gone in CURRENT: # dmesg|head -n2 OpenBSD 5.4 (GENERIC.MP) #0: Sat Jul 20 17:56:10 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP time buildsrc.sh takes 31 minutes. measured directly after building src (which was slow before): # time tar -xzpf /usr/releasedir/comp54.tgz 0m5.67s real 0m2.07s user 0m0.89s system # time tar -xzpf /usr/releasedir/man54.tgz 0m1.26s real 0m0.45s user 0m0.30s system Best Regards Andreas
Re: dhcp address in /etc/hosts
On 07/21/13 09:02, Jan Stary wrote: On Jul 20 18:34:50, dera...@cvs.openbsd.org wrote: On Jul 20 22:14:52, h...@stare.cz wrote: I believe I have bitched about this before, but I have come to it again with new install. If I use [dhcp] to configure an interface during an install, the ephemeral DHCP-assigned address gets written into /etc/hosts. That address is meaningless after the reboot, possibly even conflicting when I later decide on a fixed IP for the machine. Should it be removed from /etc/hosts after the install, when we have DNS set up and all? Should it at least be mentioned in afterboot(8)? --- afterboot.8.origSat Jul 20 22:24:03 2013 +++ afterboot.8 Sat Jul 20 22:28:51 2013 @@ -153,6 +153,13 @@ if it needs to be changed. You will also need to edit the .Pa /etc/myname file to have it stick around for the next reboot. +.Pp +Note that the hostname chosen during installation is saved in +.Pa /etc/hosts +with whatever address was used then. +If you later decide on another address for the machine, +remember to remove the conflicting one from +.Pa /etc/hosts . .Ss Verify network interface configuration The first thing to do is an .Ic ifconfig -a I don't like this diff. But perhaps because I totally hate that the installer is placing that name there. I believe that dynamically learned names should not be saved in that fashion. I don't like it either; what is the reason we are saving it there? I vaguely remember sendmail bitching about not being able to resolve its own hostname - is it that? Since we by default allow dhclient to rewrite (and thus a dhcp server to dictate) our hostname, I'm wondering if a 'lookup hostname file bind' in resolv.conf could be useful... But I expect being flamed for it. :-) /Alexander
Re: dhcp address in /etc/hosts
On Jul 20 18:34:50, dera...@cvs.openbsd.org wrote: > > On Jul 20 22:14:52, h...@stare.cz wrote: > > > I believe I have bitched about this before, > > > but I have come to it again with new install. > > > > > > If I use [dhcp] to configure an interface during an install, > > > the ephemeral DHCP-assigned address gets written into /etc/hosts. > > > > > > That address is meaningless after the reboot, possibly even > > > conflicting when I later decide on a fixed IP for the machine. > > > > > > Should it be removed from /etc/hosts after the install, > > > when we have DNS set up and all? Should it at least > > > be mentioned in afterboot(8)? > > > > > > --- afterboot.8.origSat Jul 20 22:24:03 2013 > > +++ afterboot.8 Sat Jul 20 22:28:51 2013 > > @@ -153,6 +153,13 @@ if it needs to be changed. > > You will also need to edit the > > .Pa /etc/myname > > file to have it stick around for the next reboot. > > +.Pp > > +Note that the hostname chosen during installation is saved in > > +.Pa /etc/hosts > > +with whatever address was used then. > > +If you later decide on another address for the machine, > > +remember to remove the conflicting one from > > +.Pa /etc/hosts . > > .Ss Verify network interface configuration > > The first thing to do is an > > .Ic ifconfig -a > > > > I don't like this diff. > > But perhaps because I totally hate that the installer is placing that > name there. I believe that dynamically learned names should not be > saved in that fashion. I don't like it either; what is the reason we are saving it there? I vaguely remember sendmail bitching about not being able to resolve its own hostname - is it that?
