You are not logged in.

#1 2019-09-30 14:54:00

Imo
Member
Registered: 2019-09-30
Posts: 4

Help understanding hci0 and not /dev/hci0 (Closed)

Hi
I have a doubt concerning the interface hci0 of Bluetooth low energy interface.

Some say that "everything" in linux are files... Ok, screen and prints etc seem to be maped as files but what about hci0 with is the descriptor of bluetooth low energy interface?

There is no /dev/hci0 :-(

My question appears due to this kind of service.

I have a linux box always (24h/365 days) scanning bluethooth devices in a computer that has a low capacity SSD. As you know SSD have a limited nmber of read/write sectors and if it is always near full capacity a disk error could happen even more quickly.

As per second the bluetooth interface founds (reports) ten or more near by bluetooth devices I was thinking that the file that represents the bluetooth physical interface could be a big source of problem for the SSD. Hence I thought to map/mount it in RAM as it is a file descriptor written and read multiples times per seconds, all day, all year. However I realize that there is no /dev/hci0.

However, there are these entries;

sys/kernel/debug/bluetooth/hci0
/sys/class/bluetooth/hci0
/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0

Does this mean that hci0 is not a file on the filesystem?

Would a map/mount in RAM solve the problem of multiples and constant read and writes to/from SSD?

Thanks a lot
Imo

Last edited by Imo (2019-10-01 08:45:04)

Offline

#2 2019-09-30 15:07:28

seth
Member
Registered: 2012-09-03
Posts: 49,981

Re: Help understanding hci0 and not /dev/hci0 (Closed)

Wut?

It means there's no symlink or other representation in /dev.

Neither devfs nor sysfs (/dev and /sys) have anything to do w/ your SSD but are filesystems that represent the kernel (broadly spoken) - "the filesystem" does not equate to "your disks".
To be clear: reading and writing into /dev and /sys will NOT touch your SSD.

Also modern SSDs  don't really suffer from writing wear and there's certainly absolutely NO problem w/ reading them. As a matter of fact, when NAND fails you'll only lose the ability to write it, you can still read it ad infinitum (or until the interface chip fails, which is far more common)

Offline

#3 2019-09-30 15:10:16

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: Help understanding hci0 and not /dev/hci0 (Closed)

Imo wrote:

Some say that "everything" in linux are files... Ok, screen and prints etc seem to be maped as files but what about hci0 with is the descriptor of bluetooth low energy interface?

...
However, there are these entries;

sys/kernel/debug/bluetooth/hci0
/sys/class/bluetooth/hci0
/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0

Does this mean that hci0 is not a file on the filesystem?

Note so much files, as "file like".  There are certain "files" that are dynamically generated by the kernel to convey information to user space, or to allow the user space to influence the kernel.  Files under /sys and /proc fall into this category. The contents of these 'files' do not exist on storage media (and do not cause write cycles to said media), but rather are streamed by the kernel.  Things in /dev are similar, except that the kernel uses data from physical interfaces to generate the content of those 'files'

Look at the output of mount  note that the sys filesystem is a sysfs type, not a disk volume.  Same for /proc it is a type proc. .  Similarly, /dev is a devtmpfs type.  None of those exist on physical media.

When you establish a bluetooth connection that uses a serial profile, an hci device node will be created in /dev.  See https://wiki.archlinux.org/index.php/Bl … oth_serial
I do not recall if BLE has a serial profile or not, it may only work in Bluetooth classic mode.  I could be wrong.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#4 2019-09-30 15:14:30

Imo
Member
Registered: 2019-09-30
Posts: 4

Re: Help understanding hci0 and not /dev/hci0 (Closed)

"To be clear: reading and writing into /dev and /sys will NOT touch your SSD."

Great to hear that. But just to clarify, are these fs (/dev and /sys) mounted on RAM?


"Also modern SSDs  don't really suffer ..."
Apart from the industrial ones, for the best of my knowledge, the best ones seem to spread writes across the free space, right? The problem is that if the SSD is almost full that also means that almost always the same free sectors are being written, right?

Thanks
Imo

Offline

#5 2019-09-30 15:24:46

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: Help understanding hci0 and not /dev/hci0 (Closed)

Imo wrote:

The problem is that if the SSD is almost full that also means that almost always the same free sectors are being written, right?
Imo

No.

The wear leveling mechanisms are far more clever than that.   The drive will notice that some files get written exactly once and are never or rarely updated.  Things like video files, music.  Others like program files are changed perhaps every few months. 
When the leveling algorithm needs to move a file that is written frequently to level write wearing, it is likely to swap it with one of the more static files to reduce writes in the future to worn areas.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#6 2019-09-30 15:24:52

seth
Member
Registered: 2012-09-03
Posts: 49,981

Re: Help understanding hci0 and not /dev/hci0 (Closed)

But just to clarify, are these fs (/dev and /sys) mounted on RAM?

Yesnoinaway: https://en.wikipedia.org/wiki/Sysfs
Those are not "files" as you might think of them. Reading and writing there talks to the kernel.

The wear leveler will shuffle the physical cells below the logical inodes to prevent overuse even if there's only a limited amount of cells left.
Also, depending on the mount parameters, the I/O isn't actually synced immediately - it initially only happes in the file cache (ie. the RAM)
And: https://www.ontrack.com/blog/2018/02/07 … ally-last/

Offline

#7 2019-09-30 15:32:36

Imo
Member
Registered: 2019-09-30
Posts: 4

Re: Help understanding hci0 and not /dev/hci0 (Closed)

Ok, thank you all!
I think I have to worry about other things (logs and related) and not with BLE interface descriptor as it is not a filesystem file but a "channel" to the kernel

Offline

#8 2019-09-30 16:10:21

seth
Member
Registered: 2012-09-03
Posts: 49,981

Re: Help understanding hci0 and not /dev/hci0 (Closed)

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Offline

#9 2019-09-30 20:33:49

Imo
Member
Registered: 2019-09-30
Posts: 4

Re: Help understanding hci0 and not /dev/hci0 (Closed)

Sorry. It was my first message here and I can find the option to mark thread as solved...

Offline

#10 2019-09-30 21:12:55

seth
Member
Registered: 2012-09-03
Posts: 49,981

Re: Help understanding hci0 and not /dev/hci0 (Closed)

There's no option.
As mentioned, you can edit your initial post (there's a link in the lower right corner) and alter the subject.

Offline

Board footer

Powered by FluxBB