From: Brace, D. <da...@hp...> - 2012-02-27 21:41:49
|
We have many customers who have hundreds of disk drives that are using smartmontools to monitor drive health. But they want to see an enhancement to smartmontols to make it easier to use. Typically a customer has a mixture of SAS and SATA drives installed and would like to be able to run smartmontools without having to know in advance if the drive is SAS or SATA. Currently if the drive is SATA they have to use -device=sat+cciss,N and -device=cciss,N for SAS drives. In the past I had added code to smartmontools that enabled it to determine if the drive was SAS or SATA and issue the appropriate command automatically. Would this enhancement be acceptable? If so, who would make these enhancements? Thanks, Don Brace |
From: Christian F. <Chr...@t-...> - 2012-02-27 22:27:37
|
Brace, Don wrote: > We have many customers who have hundreds of disk drives that are using smartmontools to monitor drive health. > > But they want to see an enhancement to smartmontols to make it easier to use. > > Typically a customer has a mixture of SAS and SATA drives installed and would like to be able to run > smartmontools without having to know in advance if the drive is SAS or SATA. Alex Samorukov added a ticket for your patch in Nov, 2011: http://sourceforge.net/apps/trac/smartmontools/ticket/202 There are still open issues, see the comments in the ticket and the questions below. > Currently if the drive is SATA they have to use -device=sat+cciss,N and -device=cciss,N for SAS drives. Does --device=sat+cciss,N work for all commands, including DATA OUT and 48-bit ATA commands (Try smartctl -x ...) ? > > In the past I had added code to smartmontools that enabled it to determine if the drive was SAS or SATA and issue the appropriate command automatically. Does your code work with all commands, including DATA OUT and 48-bit ATA commands (Try smartctl -x ...) ? > Would this enhancement be acceptable? Yes - this enhancements makes sense. No - the current patch likely includes an unneeded (and incomplete) re-implementation of SAT. > > If so, who would make these enhancements? I could commit the fixed patch for the next release. Thanks, Christian |
From: Alex S. <ml...@os...> - 2012-02-28 12:54:41
|
On 02/27/2012 10:40 PM, Brace, Don wrote: > Currently if the drive is SATA they have to use -device=sat+cciss,N and -device=cciss,N for SAS drives. Hi Don, I created a ticket for this long time ago. Unfortunately we never had cooperation and replies from submitter. I hope this will be changed and patches will be corrected and then accepted. See http://sourceforge.net/apps/trac/smartmontools/ticket/202 for more details. I hope that this time patches will be fixed and then commited. |
From: Bokhan A. <ap...@ng...> - 2012-02-28 17:13:23
|
Alex can you return the same function for megaraid? It's quite annoying to support mixed sas/sata enviroment for large installations. May be there is some option to force old behavior which I do not see. 28.02.2012 5:27, Christian Franke пишет: > Brace, Don wrote: >> We have many customers who have hundreds of disk drives that are using smartmontools to monitor drive health. >> >> But they want to see an enhancement to smartmontols to make it easier to use. >> >> Typically a customer has a mixture of SAS and SATA drives installed and would like to be able to run >> smartmontools without having to know in advance if the drive is SAS or SATA. > Alex Samorukov added a ticket for your patch in Nov, 2011: > http://sourceforge.net/apps/trac/smartmontools/ticket/202 > > There are still open issues, see the comments in the ticket and the > questions below. > > >> Currently if the drive is SATA they have to use -device=sat+cciss,N and -device=cciss,N for SAS drives. > Does --device=sat+cciss,N work for all commands, including DATA OUT and > 48-bit ATA commands (Try smartctl -x ...) ? > > >> In the past I had added code to smartmontools that enabled it to determine if the drive was SAS or SATA and issue the appropriate command automatically. > Does your code work with all commands, including DATA OUT and 48-bit ATA > commands (Try smartctl -x ...) ? > > >> Would this enhancement be acceptable? > Yes - this enhancements makes sense. > No - the current patch likely includes an unneeded (and incomplete) > re-implementation of SAT. > > >> If so, who would make these enhancements? > I could commit the fixed patch for the next release. > > Thanks, > Christian > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support |
From: Alex S. <ml...@os...> - 2012-02-28 19:49:40
|
Hi Artem, Initially it was done because i found that SAT can easily degrade raid and in the worst case - destroy the array. Later i identified "unsafe" commands and blocked them in the code (for Linux and FreeBSD) and now on all my arrays (about ~30 i guess) "smatctl -x /dev/sda" do not cause any problems. So its _probably_ safe to remove this. It would be great to see feedback from other users/developers before final decision. On 02/28/2012 06:13 PM, Bokhan Artem wrote: > Alex can you return the same function for megaraid? It's quite annoying > to support mixed sas/sata enviroment for large installations. May be > there is some option to force old behavior which I do not see. > > 28.02.2012 5:27, Christian Franke пишет: >> Brace, Don wrote: >>> We have many customers who have hundreds of disk drives that are using smartmontools to monitor drive health. >>> >>> But they want to see an enhancement to smartmontols to make it easier to use. >>> >>> Typically a customer has a mixture of SAS and SATA drives installed and would like to be able to run >>> smartmontools without having to know in advance if the drive is SAS or SATA. >> Alex Samorukov added a ticket for your patch in Nov, 2011: >> http://sourceforge.net/apps/trac/smartmontools/ticket/202 >> >> There are still open issues, see the comments in the ticket and the >> questions below. >> >> >>> Currently if the drive is SATA they have to use -device=sat+cciss,N and -device=cciss,N for SAS drives. >> Does --device=sat+cciss,N work for all commands, including DATA OUT and >> 48-bit ATA commands (Try smartctl -x ...) ? >> >> >>> In the past I had added code to smartmontools that enabled it to determine if the drive was SAS or SATA and issue the appropriate command automatically. >> Does your code work with all commands, including DATA OUT and 48-bit ATA >> commands (Try smartctl -x ...) ? >> >> >>> Would this enhancement be acceptable? >> Yes - this enhancements makes sense. >> No - the current patch likely includes an unneeded (and incomplete) >> re-implementation of SAT. >> >> >>> If so, who would make these enhancements? >> I could commit the fixed patch for the next release. >> >> Thanks, >> Christian >> >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Smartmontools-support mailing list >> Sma...@li... >> https://lists.sourceforge.net/lists/listinfo/smartmontools-support > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support |
From: Bokhan A. <ap...@ng...> - 2012-02-28 21:33:52
|
29.02.2012 2:49, Alex Samorukov пишет: > Hi Artem, > > Initially it was done because i found that SAT can easily degrade raid > and in the worst case - destroy the array. Later i identified > "unsafe" commands and blocked them in the code (for Linux and FreeBSD) > and now on all my arrays (about ~30 i guess) "smatctl -x /dev/sda" do > not cause any problems. So its _probably_ safe to remove this. It > would be great to see feedback from other users/developers before > final decision. I do not have problems, about 50 arrays of lsi 9240/9260/9280 > > On 02/28/2012 06:13 PM, Bokhan Artem wrote: >> Alex can you return the same function for megaraid? It's quite annoying >> to support mixed sas/sata enviroment for large installations. May be >> there is some option to force old behavior which I do not see. >> >> 28.02.2012 5:27, Christian Franke пишет: >>> Brace, Don wrote: >>>> We have many customers who have hundreds of disk drives that are >>>> using smartmontools to monitor drive health. >>>> >>>> But they want to see an enhancement to smartmontols to make it >>>> easier to use. >>>> >>>> Typically a customer has a mixture of SAS and SATA drives installed >>>> and would like to be able to run >>>> smartmontools without having to know in advance if the drive is SAS >>>> or SATA. >>> Alex Samorukov added a ticket for your patch in Nov, 2011: >>> http://sourceforge.net/apps/trac/smartmontools/ticket/202 >>> >>> There are still open issues, see the comments in the ticket and the >>> questions below. >>> >>> >>>> Currently if the drive is SATA they have to use -device=sat+cciss,N >>>> and -device=cciss,N for SAS drives. >>> Does --device=sat+cciss,N work for all commands, including DATA OUT and >>> 48-bit ATA commands (Try smartctl -x ...) ? >>> >>> >>>> In the past I had added code to smartmontools that enabled it to >>>> determine if the drive was SAS or SATA and issue the appropriate >>>> command automatically. >>> Does your code work with all commands, including DATA OUT and 48-bit >>> ATA >>> commands (Try smartctl -x ...) ? >>> >>> >>>> Would this enhancement be acceptable? >>> Yes - this enhancements makes sense. >>> No - the current patch likely includes an unneeded (and incomplete) >>> re-implementation of SAT. >>> >>> >>>> If so, who would make these enhancements? >>> I could commit the fixed patch for the next release. >>> >>> Thanks, >>> Christian >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Try before you buy = See our experts in action! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>> MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-dev2 >>> _______________________________________________ >>> Smartmontools-support mailing list >>> Sma...@li... >>> https://lists.sourceforge.net/lists/listinfo/smartmontools-support >> >> ------------------------------------------------------------------------------ >> >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> Smartmontools-support mailing list >> Sma...@li... >> https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: Christian F. <Chr...@t-...> - 2012-02-29 06:34:54
|
Alex Samorukov wrote: > Hi Artem, > > Initially it was done because i found that SAT can easily degrade raid > and in the worst case - destroy the array. Later i identified > "unsafe" commands and blocked them in the code (for Linux and FreeBSD) > and now on all my arrays (about ~30 i guess) "smatctl -x /dev/sda" do > not cause any problems. So its _probably_ safe to remove this. It > would be great to see feedback from other users/developers before > final decision. > I would suggest to add a new -d option (e.g. -d megaraid,N,auto) to enable SAT auto-detection on demand: Something like this should work: class linux_megaraid_device ... { public: linux_megaraid_device(..., bool enable_auto); ... private: bool m_enable_auto; }; linux_megaraid_device::linux_megaraid_device(..., bool enable_auto) ..., m_enable_auto(enable_auto) {...} smart_device * linux_megaraid_device::autodetect_open() { ... { ata_device * newdev = smi()->autodetect_sat_device(this, req_buff, len); if (newdev) { if (!enable_auto) { newdev->close(); newdev->set_err(ENOSYS, "SATA device detected,\n" "MegaRAID SAT layer is reportedly buggy," " use '-d megaraid,N,auto' to try anyhow"); } return newdev; } } ... } smart_device * linux_smart_interface::get_custom_smart_device(...) { ... n1 = n2 = -1; if (sscanf(type, "megaraid,%d%n,auto%n", &disknum, &n1, &n2) == 1 && (n1 == strlen(type) || n2 == strlen(type))) { // TODO: Add a disknum range check return new linux_megaraid_device(this, name, 0, disknum, (n2 > 0)); } ... } Christian |
From: Bokhan A. <ap...@ng...> - 2012-02-29 16:57:20
|
29.02.2012 13:34, Christian Franke пишет: > Alex Samorukov wrote: >> Hi Artem, >> >> Initially it was done because i found that SAT can easily degrade >> raid and in the worst case - destroy the array. Later i identified >> "unsafe" commands and blocked them in the code (for Linux and >> FreeBSD) and now on all my arrays (about ~30 i guess) "smatctl -x >> /dev/sda" do not cause any problems. So its _probably_ safe to remove >> this. It would be great to see feedback from other users/developers >> before final decision. >> > > I would suggest to add a new -d option (e.g. -d megaraid,N,auto) to > enable SAT auto-detection on demand: That would be great |
From: Christian F. <Chr...@t-...> - 2012-02-29 17:01:06
Attachments:
linux-megaraid-auto.patch
|
Christian Franke wrote: > Alex Samorukov wrote: >> Hi Artem, >> >> Initially it was done because i found that SAT can easily degrade >> raid and in the worst case - destroy the array. Later i identified >> "unsafe" commands and blocked them in the code (for Linux and >> FreeBSD) and now on all my arrays (about ~30 i guess) "smatctl -x >> /dev/sda" do not cause any problems. So its _probably_ safe to remove >> this. It would be great to see feedback from other users/developers >> before final decision. >> > > I would suggest to add a new -d option (e.g. -d megaraid,N,auto) to > enable SAT auto-detection on demand: Proposed patch attached. Please test if possible. Thanks, Christian |
From: Christian F. <Chr...@t-...> - 2012-03-06 16:53:29
|
Christian Franke wrote: > Christian Franke wrote: >> Alex Samorukov wrote: >>> Hi Artem, >>> >>> Initially it was done because i found that SAT can easily degrade >>> raid and in the worst case - destroy the array. Later i identified >>> "unsafe" commands and blocked them in the code (for Linux and >>> FreeBSD) and now on all my arrays (about ~30 i guess) "smatctl -x >>> /dev/sda" do not cause any problems. So its _probably_ safe to >>> remove this. It would be great to see feedback from other >>> users/developers before final decision. >>> >> >> I would suggest to add a new -d option (e.g. -d megaraid,N,auto) to >> enable SAT auto-detection on demand: > > Proposed patch attached. Please test if possible. I'm working on a controller independent solution which may obsolete this patch. Will be committed soon. Christian |
From: Christian F. <Chr...@t-...> - 2012-03-06 20:31:46
|
Christian Franke wrote: > Christian Franke wrote: >> Christian Franke wrote: >>> Alex Samorukov wrote: >>>> Hi Artem, >>>> >>>> Initially it was done because i found that SAT can easily degrade >>>> raid and in the worst case - destroy the array. Later i identified >>>> "unsafe" commands and blocked them in the code (for Linux and >>>> FreeBSD) and now on all my arrays (about ~30 i guess) "smatctl -x >>>> /dev/sda" do not cause any problems. So its _probably_ safe to >>>> remove this. It would be great to see feedback from other >>>> users/developers before final decision. >>>> >>> >>> I would suggest to add a new -d option (e.g. -d megaraid,N,auto) to >>> enable SAT auto-detection on demand: >> >> Proposed patch attached. Please test if possible. > > I'm working on a controller independent solution which may obsolete > this patch. Will be committed soon. Done. If possible please test r3519. Should work for megaraid and cciss if SAT layers return proper VENDOR strings: # smartctl -d sat,auto+megaraid,N /dev/ice # smartctl -d sat,auto+cciss,N /dev/ice Thanks, Christian |
From: Bokhan A. <ap...@ng...> - 2012-03-07 17:21:39
|
07.03.2012 3:31, Christian Franke пишет: > > Done. If possible please test r3519. > > Should work for megaraid and cciss if SAT layers return proper VENDOR > strings: > > # smartctl -d sat,auto+megaraid,N /dev/ice > > # smartctl -d sat,auto+cciss,N /dev/ice > "sat" is quite strange here. "-d megaraid,N,auto" or "-d auto+megaraid,N" are more understandable. > > Thanks, > Christian > |
From: Christian F. <Chr...@t-...> - 2012-03-07 18:58:55
|
Bokhan Artem wrote: > 07.03.2012 3:31, Christian Franke пишет: >> >> Done. If possible please test r3519. >> >> Should work for megaraid and cciss if SAT layers return proper VENDOR >> strings: >> >> # smartctl -d sat,auto+megaraid,N /dev/ice >> >> # smartctl -d sat,auto+cciss,N /dev/ice >> > "sat" is quite strange here. "-d megaraid,N,auto" or "-d > auto+megaraid,N" are more understandable. Using "sat" is IMO not strange because this actually *is* a SAT auto detection. Option "-d sat[,auto]+TYPE" provides a controller and platform independent method that should work with any SCSI controller TYPE which provides a SAT layer. This is not the case for "-d megaraid,N,auto". Using "-d auto+TYPE" is IMO too generic for a "SAT or SCSI" detection, "-d sat-scsi+TYPE" may be an alternative. Before we discuss such cosmetic changes further, the functionality should be tested with some real world controllers. Thanks, Christian |
From: Bokhan A. <ap...@ng...> - 2012-03-07 19:18:53
|
08.03.2012 1:58, Christian Franke пишет: > Using "-d auto+TYPE" is IMO too generic for a "SAT or SCSI" detection, > "-d sat-scsi+TYPE" may be an alternative. > > Before we discuss such cosmetic changes further, the functionality > should be tested with some real world controllers. > We have holidays here until next week. I will report then. > Thanks, > Christian > |
From: Artem B. <ap...@ng...> - 2012-03-24 14:57:38
|
On 07.03.2012 03:31, Christian Franke wrote: > Done. If possible please test r3519. > > Should work for megaraid and cciss if SAT layers return proper VENDOR strings: > > # smartctl -d sat,auto+megaraid,N /dev/ice > > # smartctl -d sat,auto+cciss,N /dev/ice Works as expected with megaraid. > > > Thanks, > Christian > |
From: Christian F. <Chr...@t-...> - 2012-03-25 15:25:18
|
Artem Bokhan wrote: > On 07.03.2012 03:31, Christian Franke wrote: >> Done. If possible please test r3519. >> >> Should work for megaraid and cciss if SAT layers return proper VENDOR >> strings: >> >> # smartctl -d sat,auto+megaraid,N /dev/ice >> >> # smartctl -d sat,auto+cciss,N /dev/ice > > Works as expected with megaraid. Thanks for testing. @ Don Brace: Any result for CCISS ? Thanks, Christian |