Disk drives and disk drive-like devices are "dumb." You ask it for an LBA, it gives you back the 512, 2048, or 4096 bytes that it contains; vice versa for writing.
A filesystem layer lets you say "I want c:\users\public\documents\whatever.doc" and perform streaming operations on that (open, read, write, seek, close) - it translates from name-addressable locations to a series of requests to read/write LBAs.
So the filesystem layer has two sides, the one side that communicates with the disk drive-like (or block) device, and the other side that talks to the operating system. This is where specificity to the operating system comes into play. Usually the block device side of the filesystem is a device driver, and the operating system side is an API useable by applications. But these are just interfaces and don't really have to affect the underlying operation of the filesystem layer.
All filesystems cause additional data to be written and read outside file data, in order to keep track of information about files, i.e. to record permissions, attributes, etc.
There is a bit of chicken-and-egg problem with booting - as operating system files are stored on the filesystem, but how are they loaded if the filesystem layer is not active yet? Linux solves this issue with either an initial ram disk or by building in the filesystem code as part of the kernel. Windows solves this issue by giving the Windows bootloader the ability to read FAT and NTFS partitions. Bootloaders can be dumb, like most classic BIOS bootloaders which only load LBA 0 and execute it and expect that code to pick up afterwards, or fairly intelligent and with small filesystem layers of their own, such as UEFI, U-boot, etc.
LVM is not a filesystem. It takes one or more block devices and abstracts it into another "virtual" block device (in
/dev/mapper - anything in
/dev/mapper is a virtual block device). You put a filesystem "on top of" an LVM in the same way you would put a filesystem "on top of" a partition. LVM is another layer in between one or more device drivers and the filesystem, converting reads and writes to LBAs on the virtual block device to one or more other block devices. Yes, an LVM can be a virtual block device and you can have a cascade of them.