Re: disk devices speed is ugly
On 02/15/2012 05:50 AM, Scott Long wrote: What would be nice is a generic caching subsystem that any FS can use - similar to the old block devices but with hooks to allow the FS to request read-ahead, advise of unwanted blocks and ability to flush dirty blocks in a requested order with the equivalent of barriers (request Y will not occur until preceeding request X has been committed to stable media). This would allow filesystems to regain the benefits of block devices with minimal effort and then improve performance cache efficiency with additional work. Any filesystem that uses bread/bwrite/cluster_read are already using the generic caching subsystem that you propose. This includes UDF, CD9660, MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local storage filesystem in the tree except for ZFS. Not all of them implement VOP_GETPAGES/VOP_PUTPAGES, but those are just optimizations for the vnode pager, not requirements for using buffer-cache services on block devices. As Kostik pointed out in a parallel email, the only thing that was removed from FreeBSD was the userland interface to cached devices via /dev nodes. This has nothing to do with filesystems, though I suppose that could maybe sorta kinda be an issue for FUSE?. May be its possible to provide some generic interface for fuse based filesystems to use this generic cache? I can test it and report performance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disk devices speed is ugly
On 02/13/2012 02:28 PM, Gary Palmer wrote: Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. But _that_ can be fixed with the appropriate application of a sensible caching layer. With every application? :) Are you know anyone who wants to do this? At least for 3 fuse filesystems. The filesystem is the *BEST* place to do caching. It knows what metadata is most effective to cache and what other data (e.g. file contents) doesn't need to be cached. Any attempt to do this in layers between the FS and the disk won't achieve the same gains as a properly written filesystem. e.g. in a UFS implementation the disk layer may see a lot of I/Os for blocks, not necessarily sequential, as a program lists a directory and stats all the files which pulls in the inode tables. The filesystem knows that it needs the inode tables and is likely to need not only the current inode table disk block but subsequent ones also, and instead of requesting the disk sector that it needs to service the immediate stat(2) request but maybe the next few also. Without that insight into whats going on it is difficult to see how a highly effective cache could be done at the geom layer. I think we are playing in a captain obvious. I have nothing against statement that FS is a best place for caching. Also - i am absolutely sure that its better to have kernel space fs driver then FUSE one. But unfortunately there is no kernel space driver for the exfat, kernel driver for ntfs is ugly and buggy (and r/o) and i don`t think that anyone is going to change this. And i really don`t understand why are you trying to tell that it cannot be effective when its so easy to proof that it can. Just try this with fuse based filesystems in Linux, and you will get speed compared to underlying device (especially on relatively slow USB devices). Then try the same code on FreeBSD to see how ugly things are. And yes, in ideal world ever fs needs to have good written cache implementation and kernel should not care about caching raw devices at all. But as i mentioned before - there is no kernel-space drivers with a good cache implementation for this 2 widely used systems (and probably not only). Linux is a good example that device-level caching works, and works fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disk devices speed is ugly
On 02/12/2012 01:54 AM, Adrian Chadd wrote: Hi, What about the disk access is unaligned? Do you mean not sector aligned? or? Hi. Sector aligned. This is a common problem people face doing disk IO analysis. The whole point about not allowing unaligned access is to make the disk IO path cleaner. It does mean that the filesystem code (and GEOM modules involved) need to be smarter. If the filesystem is doing ridiculously unaligned access then it likely should be fixed. Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disk devices speed is ugly
On 02/13/2012 06:27 AM, Adrian Chadd wrote: On 12 February 2012 09:34, Alex Samorukovm...@os2.kiev.ua wrote: Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. But _that_ can be fixed with the appropriate application of a sensible caching layer. With every application? :) Are you know anyone who wants to do this? At least for 3 fuse filesystems. Also, caching in user-land is much slower and more dangerous. There is a libublio utility which is done to provide userland caching (it implements pwrite/pread replacement) and it is in use by this 2 ports. So if there are alignment issues, let's fix those up first so filesystems act sensibly with the block device layer. Then yes, adding a caching layer that works. I didn't get very good performance with g_cache when i last tried it. Because its very primitive. Once again - try to compare performance of the exfat or ntfs-3g on Linux and FreeBSD. Raw device speed (i used USB) is pretty the same, but resulting speed is very different, as well as I/O characteristic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New BSD Installer
On 02/10/2012 06:56 PM, Joe Holden wrote: Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Hi, I am highly against reverting. Old installer is not GPT aware and in fact is unmaintained for a very long time. About ftp - its probably needs to be handled better, but most of the user i think using cd/dvd image, so it is not an issue. And new installer is written on shell, so i think its better to fix broken parts then to revert it to outdated and unmaintained code. P.S. i personally had no problems with a new installer, used it from DVD. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disk devices speed is ugly
On 01/31/2012 11:19 AM, Harald Schmalzbauer wrote: schrieb Alex Samorukov am 26.01.2012 14:52 (localtime): Hi, I ported exfat fuse module to FreeBSD (PR 164473) and found that it works much slower then on Linux. I found 2 reasons for this: Thanks a lot! I saw the new port :-) Hope that someone can help you improove fusefs-kmod. I remember more porters were blaming FreeBSDs fusefs support making their work hard/impossible (TrueCrypt). Hopefully some kernel hacker will read and help... Thank you for comment. It is now mostly not about fuse itself, but about non-buffered raw device access. I really think that something like improved geom_cache should solve this. I`ll add soon updated version of the patch with [optional] libublio support. This improves performance a lot. Read speed is comparable with Linux (about 20 Mb/sec on my old USB) and write is much faster aw well (but not so good as in Linux and with a lot read requests for align). Also i contacted upstream about unaligned writes and he told that it is in his todo list, but probably after 1.0.0 version, because it will require a lot of changes in the code. Also i found a libexfat bug in a fat time handling and creating patch to use freebsd code for this instead. So if you are using exfat any testing and comments are welcome. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
disk devices speed is ugly
Hi, I ported exfat fuse module to FreeBSD (PR 164473) and found that it works much slower then on Linux. I found 2 reasons for this: 1) FreeBSD kernel do not allow to have nonalignment access to device with standard read/write commands. mmap to the entire disk (/dev/da0s1) doesn`t work also (EINVAL). When its not a big deal for read requests, for write it becomes a real issue - to write non-aligned data i need to read beginning and end of the block. So in fact for one write request i can get 2 reads. 2) It seems that there is a very simple read caching on such devices without write caching at all. It makes write performance enormously slow. I found geom_cache module, but it provides only read optimization. I decided to compare speed on Linux and FreeBSD and below are my results. I used old USB flash drive to do the tests. Read Speed of 100Mb: Linux 3.0.0: 22.7 Mb/sec FreeBSD: 10.22 Mb/sec FreeBSD + gcache: 18.75 Mb/sec (!) Write speed of 100Mb file: Linux: 90Mb/sec (cache, much higher then device speed) FreeBSD: 0.52 Mb/sec (!) FreeBSD + gcache: 0.52 Mb/sec As you could see write performance is enormously slow. May be we need to create some geom provider for such caching or i am missing something? I think, that other fuse modules like ntfs-3g and fuse-ext4 having same issue. Also i found that fuse4bsd itself is non stable and may crash the system without any visible reasons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
On 11/08/2011 09:33 PM, Marat N.Afanasyev wrote: why :) just a little misunderstanding, I suppose ;) I just showed what I'd expect from #smartctl -a -d 3ware,0 /dev/twa0 in case of sas drive on channel 0 Yes. BTW, if you able to provide access to the BSD box with MFI and SAS i could fix defect sectors status report. For the twa/SAS much work needs to be done, but if there is anyone with such controller and hardware (not in production!) i could try, at least. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
On 11/07/2011 02:06 PM, Jeremy Chadwick wrote: On Mon, Nov 07, 2011 at 04:53:36PM +0400, Marat N.Afanasyev wrote: btw, 3dm can tell about reallocated sector count on sas somehow, while smartctl cannot, even on supported controller :( I think this is getting into a separate discussion topic. I realise we're discussing SAS, but what's shown above looks pure and total SCSI output from smartmontools. I'm very familiar with it (we predominantly used SCSI disks at my workplace up until ~1 year ago). I will be satisfied with scsi-like output of smartctl for my sas drive on twa controller ;) Did you actually look at the output I provided? It's more or less the same, minus data which you want that isn't being shown (at all). That includes things like drive manufacturing date, etc.. The problem could be in one of the following layers: 1. smartmontools itself Hi Jeremy, It is smartmontools itself problem. On twa (3ware devices) we are using ATA-type of packets to speak with the device. It is fine for ATA/SATA disks, but not for SATA, which are using SCSI commands. The code for the SCSI conversation just needs to be written (btw, the same on Linux). Driver itself provides TWA_FW_CMD_EXECUTE_SCSI type of the packet, so it probably (!) possible to speak with underlying disks using it, but it needs to be tested. The problem is that i have no such controllers or drives. I could try to add this functionality if anyone will provide me access, but it should not be production system with any important data. E.g. when i was working on LSI code i had array degradations and controller hangs on legitimate SAT commands. 2. CAM translation layer (e.g. pass(4) or related bits) 3. twa(4) driver 2. is not in use, smartmontools using ioctl api to send commands to firmware. 3. - under the question. 4. 3Ware controller firmware 4. Yes, needs to be tested. It is common to see bugs in firmware in this area, it is not usually well tested (LSI with SAT protocol is a good example, i did workaround for this in recent smartmontools update). It is possible to determine if #1 and #2 are responsible by enabling CAMDEBUG and/or using camcontrol debug to watch all CDBs which are submit to the controller. I'm not sure which one is responsible for obtaining defect counts and so on -- I would need to review SAS and/or SCSI specifications. The information should be available per T10's SCSI and SAS specification documents. An alternate way to check would be to boot into a Linux LiveCD and install smartmontools (in RAM) and see if it provides the data. It would not. Just because SCSI interface for this driver is not implemented. My point: don't be so quick to assume smartmontools is responsible when there are 4 (maybe even 5) layers to how SCSI I/O makes it to the actual drive. This is one of the many reasons I try to avoid hardware RAID controllers -- too much crap between me and the device I wish to speak to. Its controversy statement. From my own point of view - device authors should implement passX devices for the disks like it done on mfip.ko or with Adaptec (at least on Linux). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfip and smartctl Re: smartctl / mpt on 9.0-RC1
On 11/07/2011 02:47 PM, Andrew Boyer wrote: [GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on'] No self-tests have been logged Long (extended) Self Test duration: 1740 seconds [29.0 minutes] btw, 3dm can tell about reallocated sector count on sas somehow, while smartctl cannot, even on supported controller :( Notice how the device type is 31? The mfip driver masks off the SCSI INQUIRY peripheral device type bits to prevent CAM from attached da* devices to the disks. See sys/dev/mfi/mfi_cam.c, search for T_DIRECT. That confuses smartctl and prevents it from displaying information like the Grown Defect List. I added a local hack to smartctl to interpret a peripheral device type of 0x1f (unknown or missing) to 0x0 (disk), but I don't think the hack is appropriate for general consumption. What we need is better way for mfi and aac to block CAM from attaching without corrupting the inquiry results I can add hack to the sources with checking if underlying driver is mfi (there are already some for buggy SAT fw implementation). It is probably easiest way to do this. I just tested - firmware itself returns correct (disk) status. Of course in the feature its better to fix in mfi_cam to avoid such hacks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
On 11/07/2011 03:10 PM, Jeremy Chadwick wrote: I see. I wasn't aware there was an ioctl(2) interface to twa(4). This makes me wonder: why does Marat use /dev/passX as his device when using smartctl? Because Marat using LSI mfi (not 3ware twa!) driver in this case. mfip.ko exports /dev/passX devices for every disk in the raid. Could this have some bearing on why he doesn't see the necessary data returned from (if even submit to) the underlying disk? The syntax of his command was: smartctl -a /dev/pass1. I would have expected the syntax to be smartctl -a -d 3ware,1 /dev/twa. What I'm trying to get at here is whether or not smartmontools does the right thing in this situation. Does the output differ between the above two syntaxes? I don't see any mention in twa(4)'s man page that pass(4) is even registered/used -- though I do see it mentioned that CAM is used by twa(4). Smartmontools will not work on twa with SAS drives, because it is using IOCTL packet format for the ATA protocol. And we need to use SCSI packets to speak with SAS devices. This code is currently not written. Furthermore, later comments below indicate CAM isn't involved, which further confuses me. Can someone help relieve my confusion on this matter? Because Marat provided output for another controller and another driver. For me it is also unclear why :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [smartmontools-support] smartctl / mpt on 9.0-RC1
This is fixed by me in SVN. Also fix already applied in the ports, so please update your smartmontools port. On 11/02/2011 10:57 PM, Frank Razenberg wrote: Ever since I tried 9.0-RC1 I haven't been able to read SMART values of the disks attached to my Intel SASUC8i (LSI 1068e rebrand) controller with smartctl. Similar disks on motherboard SATA ports can be queried as expected. # smartctl -a /dev/da0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Segmentation fault (core dumped) The controller was flashed to run in IT-mode. The relevant smartctl.core dump is available at http://files.zzattack.org/smartctl.core.zip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
On 11/06/2011 04:52 PM, Marat N.Afanasyev wrote: I wonder is there a possibility to monitor sas drives on twa controllers? Hi Marat, I have no access to such hardware so don`t know if it works or not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
it doesn't work :( sata drives are accessible, but for sas all we have: # smartctl -d 3ware,0 -a /dev/twa0 smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-RELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01) WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0) Smartctl: Device Read Identity Failed (not an ATA/ATAPI device) A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Ok, looking in the code i found that on 3ware device only ata_command_interface is implemented (with TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface actually supports SAS drives at all. From the quick view of the sources i found TWE_Command_ATA packet description, but nothing related to SCSI/SATA packets. So i am not sure that it is possible at all. If you know any tool which able to get health information for SAS drives we can try to debug ioctl it using to find the way to talk with disk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
On 11/06/2011 09:37 PM, Alex Samorukov wrote: Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01) WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0) Smartctl: Device Read Identity Failed (not an ATA/ATAPI device) A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Ok, looking in the code i found that on 3ware device only ata_command_interface is implemented (with TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface actually supports SAS drives at all. From the quick view of the sources i found TWE_Command_ATA packet description, but nothing related to SCSI/SATA packets. So i am not sure that it is possible at all. If you know any tool which able to get health information for SAS drives we can try to debug ioctl it using to find the way to talk with disk. One more update - there is TWA_FW_CMD_EXECUTE_SCSI command in the twa driver, so it should be possible to get required data. I have no access to such hardware, but if anyone if going to provide it - i could try at least. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
Hello, I am smartmontools developer and FreeBSD port maintainer. If you could provide shell access to the affected system i can try to debug issue. I have no access to the mpt devices myself and it is unclear what going on from provided backtrace. On 11/03/2011 09:40 AM, Frank Razenberg wrote: Was this system upgraded from RELENG_8 to RELENG_9, or was a fresh install of 9.x put on it directly? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
Thank you. I currently got shell, but user-only, what is useless for me ;-) (All ioctl/cam commands require superuser) I asked for the root and now waiting for it. You can also provide shell so i will have more boxes to test. I am expecting some very trivial bug caused by some wrong data returned from the driver without strict check in smartctl. On 11/03/2011 07:43 PM, James wrote: On Thu, Nov 3, 2011 at 12:12 PM, Alex Samorukovm...@os2.kiev.ua wrote: I am smartmontools developer and FreeBSD port maintainer. If you could provide shell access to the affected system i can try to debug issue. I have no access to the mpt devices myself and it is unclear what going on from provided backtrace. Hi Alex. If you're unable to get shell access from Frank, I'd be glad to help out. I have mps(4) and mpt(4) hardware available and experience the same bug. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
Thank you,
it is really caused by MFC r225950 and smartctl way to detect sense
length. I decided not to add ifdefs, but change the logic.
I fixed this in SVN [1], patch in the unified diff format could be
downladed at [2]. Please test this, and if it works fine - i will submit
PR to the port.
[1]
https://sourceforge.net/apps/trac/smartmontools/changeset?old_path=%2Ftrunk%2Fsmartmontools%2Fos_freebsd.cppold=3468new_path=%2Ftrunk%2Fsmartmontools%2Fos_freebsd.cppnew=3467
[2]
https://sourceforge.net/apps/trac/smartmontools/changeset?format=diffnew=3467old=3468new_path=trunk%2Fsmartmontools%2Fos_freebsd.cppold_path=trunk%2Fsmartmontools%2Fos_freebsd.cpp
:On 11/03/2011 08:05 PM, Thomas Eberhardt wrote:
Hi. I got the same problem. After some debugging I came up with the
following patch:
--- os_freebsd.cpp.orig 2011-10-06 18:43:44.0 +0200
+++ os_freebsd.cpp 2011-10-23 11:19:31.492599837 +0200
@@ -1044,8 +1044,13 @@
}
if (iop-sensep) {
+#if CAM_VERSION 0x16
memcpy(iop-sensep,(ccb-csio.sense_data),sizeof(struct
scsi_sense_data));
iop-resp_sense_len = sizeof(struct scsi_sense_data);
+#else
+memcpy(iop-sensep,(ccb-csio.sense_data),sizeof(struct
scsi_sense_data_fixed));
+iop-resp_sense_len = sizeof(struct scsi_sense_data_fixed);
+#endif
}
iop-scsi_status = ccb-csio.scsi_status;
On 03.11.2011, at 19:52, Alex Samorukov wrote:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
On 11/03/2011 08:37 PM, James wrote: On Thu, Nov 3, 2011 at 1:52 PM, Alex Samorukovm...@os2.kiev.ua wrote: Thank you. I currently got shell, but user-only, what is useless for me ;-) (All ioctl/cam commands require superuser) I asked for the root and now waiting for it. You can also provide shell so i will have more boxes to test. I am expecting some very trivial bug caused by some wrong data returned from the driver without strict check in smartctl. No problem. Send me your public key privately and I'll set you up. Could you please try to build latest svn version (see [1]) ? I think i fixed this bug. [1] https://sourceforge.net/apps/trac/smartmontools/wiki/Download ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: smartctl / mpt on 9.0-RC1
On 11/03/2011 09:35 PM, James wrote: Thanks, Alex. Looks like you fixed it. smartctl no longer segfaults. Thank you for testing. I submitter PR [1] with this patch. It also contain patch to avoid problems with SATA drives on LSI (SAS) controllers. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=162276 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bad sector in gmirror HDD
You can run long self-test in smartmontools (-t long). Then you can get failed sector number from the smartmontools (-l selftest) and then you can use DD to write zero to the specific sector. Also i am highly recommending to setup smartd as daemon and to monitor number of relocated sectors. If they will grow again - then it is a good time to utilize this disk. [root@bast:~] # dd of=/dev/null if=/dev/ad2 bs=1m conv=noerror dd: /dev/ad2: Input/output error 2717+0 records in 2717+0 records out 2848980992 bytes transferred in 127.128503 secs (22410246 bytes/sec) dd: /dev/ad2: Input/output error 38170+1 records in 38170+1 records out 40025063424 bytes transferred in 1544.671423 secs (25911701 bytes/sec) [root@bast:~] # That seems to indicate two problems. Are those the values I should be using with dd? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bad sector in gmirror HDD
The SMART tests you did didn't really amount to anything; no surprise. short and long tests usually do not test the surface of the disk. There are some drives which do it on a long test, but as I said before, everything varies from drive to drive. It is not correct statement, sorry. Long test trying to read all the data from surface (and doing some other things). // one of the smartmontools developers and sysutils/smartmontools maintainer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
Hi, I just tried your test on -STABLE + 1 fix from current [1] and got no trap. dtrace: buffer size lowered to 2m CPU IDFUNCTION:NAME 4 42224accept:return nc accept:return Assertion failed: (dpr != NULL), file /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, line 751. Abort (core dumped) Also 1st dtrace was killed as well. I tried 2 times with the same result. Box is amd64. This is bt from gdb: (gdb) bt #0 0x000800fa2f9c in thr_kill () from /lib/libc.so.7 #1 0x00080103f6cb in abort () from /lib/libc.so.7 #2 0x000800786758 in dt_proc_lookup () from /lib/libdtrace.so.2 #3 0x0008007867db in dt_proc_lock () from /lib/libdtrace.so.2 #4 0x0008007a5bcb in dt_print_ustack () from /lib/libdtrace.so.2 #5 0x0008007a8504 in dt_print_agg () from /lib/libdtrace.so.2 #6 0x0008007a88ca in dtrace_consume () from /lib/libdtrace.so.2 #7 0x00080077e1a2 in dtrace_work () from /lib/libdtrace.so.2 #8 0x004044ba in ?? () #9 0x0040222e in ?? () [skip] [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/159064 On 07/26/2011 03:20 AM, maestro something wrote: Hi, when using the ustack action on the latest FreeBSD8.2 i386 the kernel panics. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
dtrace/mysqld
If anyone interested - i was able to compile dtrace support in mysql-server55 port. During this i found a bug in dtrace/bsd - if it is running more then 1 time on the same object (this is the case for mysqld) then object is broken. I was able to do workaround (with preserving original object and then copying it) and then everything compiled and started correctly. This is an example: bsd# ./work/mysql-5.5.14/support-files/dtrace/query-time.d dtrace: buffer size lowered to 2m Who Database QueryTime(ms) root@localhost mysqlselect sleep(1) from user limit 11000 root@localhost mysqlselect * from user limit 1 0 I will try to cleanup my patches (its currently very dirty hacks) and submit them to the mysql bugtracker (and port). Feel free to contact me if you want to test this (or to fix dtrace/obects bug). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Dtrace with PHP scripts works on FreeBSD8-STABLE!
Hello,
I was able to compile [1] and and run PHP Dtrace provider on
FreeBSD-STABLE. Everything works as expected and looks very cool. It
works both from Apache (mod_php) and cli. If there are port commiters
with dtrace experience - please, take it.
Below there is a small demo:
This is a test script:
?php
/* useless dtrace demo script */
$file = file_get_contents(test.php); /* classless func. */
$demo = new demoClass(); /* call constructor */
$demo-PrintTest();
class demoClass{
function demoClass(){
@chdir(/notexists);
}
function PrintTest(){
echo TEST\n;
}
}
?
This is the most basic output to demonstrate how provider works:
# dtrace -n 'php*::: /arg0/
{printf(\t\t%s%s%s,copyinstr(arg3),copyinstr(arg4),copyinstr(arg0))}'
dtrace: description 'php*::: ' matched 24 probes
dtrace: buffer size lowered to 2m
CPU IDFUNCTION:NAME
2 44455 php_dtrace_execute_internal:function-entry
file_get_contents
2 44457 php_dtrace_execute_internal:function-return
file_get_contents
2 44456 php_dtrace_execute:function-entry
demoClass::demoClass
2 44455 php_dtrace_execute_internal:function-entry chdir
2 44457 php_dtrace_execute_internal:function-return chdir
2 44458 php_dtrace_execute:function-return
demoClass::demoClass
2 44456 php_dtrace_execute:function-entry
demoClass::PrintTest
2 44458 php_dtrace_execute:function-return
demoClass::PrintTest
As you could see there is information about all functions (and
classnames) in our test.
Also there is a possibility to trace syscalls used by PHP function. This
is output from ./php_syscolors.d (with minor modifications):
for the file_get_contents (reads file to variable):
1 16019/100898 6 test.php:4func -
file_get_contents
1 16019/100898 18 :-syscall- __getcwd
1 16019/100898 8 :-syscall - __getcwd
1 16019/100898 8 :-syscall-
clock_gettime
1 16019/100898 4 :-syscall - clock_gettime
1 16019/100898 5 :-syscall- open
1 16019/100898 9 :-syscall - open
1 16019/100898 5 :-syscall- fstat
1 16019/100898 5 :-syscall - fstat
1 16019/100898 4 :-syscall- lseek
1 16019/100898 4 :-syscall - lseek
1 16019/100898 5 :-syscall- fstat
1 16019/100898 4 :-syscall - fstat
1 16019/100898 4 :-syscall- read
1 16019/100898 6 :-syscall - read
1 16019/100898 9 :-syscall- read
1 16019/100898 5 :-syscall - read
1 16019/100898 4 :-syscall- read
1 16019/100898 4 :-syscall - read
1 16019/100898 5 :-syscall- close
1 16019/100898 10 :-syscall - close
1 16019/100898 8 test.php:4func - file_get_contents
Of course it is possible to use aggregations, filtering and all other
dtrace features.
Problems: I found that buffer size in dtrace is always about 2m. I am
using a lot of events while trying to debug running web server.
Todo: latest PHP alpha releases include dtrace support internally (and
it is extended, compared to this pecl extension). Currently build
failing on BSD and i had no time to investigate problem source (i think
they are using some ugly linker hacks). It would be great to get it
fixed before PHP release to have it in FreeBSD out of the box.
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=158983
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
